Please refer to RP-201385 for detailed scope of the WI
R1-2005746 Work plan for WI on NR sidelink enhancement LG Electronics
R1-2006167 On Sidelink Enhacement Work Item Samsung
Primary focus for this meeting, by reusing TR 36.843 and/or TR 38.840
R1-2005254 Sidelink evaluation methodology update for power saving Huawei, HiSilicon
R1-2005309 Analysis on sidelink evaluation methodology ZTE, Sanechips
R1-2005402 Discussion on sidelink evaluation methodology vivo
R1-2005499 Discussion of sidelink evaluation methodology update for power saving Nokia, Nokia Shanghai Bell
R1-2005595 Sidelink evaluation updates for V2X FUTUREWEI
R1-2005610 Discussion on sidelink evaluation methodology for power saving ITRI
R1-2005641 Evaluation methodology for sidelink power saving MediaTek Inc.
R1-2005690 Discussion on evaluation methodology for sidelink enhancement CATT
R1-2005747 Discussion on sidelink evaluation methodology update for power saving LG Electronics
R1-2005838 Discussion on sidelink evaluation methodology update for power saving Lenovo, Motorola Mobility
R1-2005895 Sidelink evaluation methodology update for UE power saving Intel Corporation
R1-2006012 Discussion on evaluation methodology for SL power saving OPPO
R1-2006168 On Sidelink Evaluation Methodology Updates for Power Saving Samsung
R1-2007003 V2X Channel Model Updates for Pedestrians InterDigital, Inc. (rev of R1-2006182)
R1-2006266 Sidelink evaluation methodology for power saving Spreadtrum Communications
R1-2006443 Evaluation assumptions and methodology for power saving Ericsson
R1-2006506 On Sidelink Power Consumption Model Apple
R1-2006624 Discussion on sidelink evaluation methodology update for power Saving Xiaomi
R1-2006746 Discussion on sidelink evaluation methodology for power saving NTT DOCOMO, INC.
R1-2006827 Evaluation Methodology for Power Saving in Sidelink Qualcomm Incorporated
[102-e-NR-SL_enh-01] – Seungmin (LGE)
Email discussion/approval using the summary as a starting point, focusing on simulation assumptions
R1-2007411 Summary for AI 8.11.1 SL evaluation methodology update for power saving Moderator (LG Electronics)
Decision: As per email decision posted on August 31st,
Agreements:
· For reference configuration for power consumption model,
o 14 SL symbols in a slot (including AGC and TX-RX switching period)
o SL sub-carrier spacing (SCS)
§ 30 kHz SCS for FR1
o SL BWP size
§ 100 MHz for FR1
o 2 OFDM symbols for PSCCH (excluding AGC symbol)
o TX antenna port (AP)
§ 1 TX AP for FR1
o RX AP
§ 4 RX APs for FR1
o TX power of {0 dBm, 23 dBm} for FR1
· Note that FR2 is not precluded as an optional/additional reference configuration, and companies are encouraged to provide power consumption model for FR2.
· Note that 15 kHz SCS is not precluded as an optional/additional reference configuration, and companies are encouraged to provide power consumption model for 15 kHz SCS.
Agreements:
· For evaluation, the followings are baseline
o 2 RX APs
o 1 TX AP
o 40 MHz for SL BWP size
· Note that parameters or cases other than baseline is not precluded for evaluation, and companies are encouraged to provide the assumptions in details.
Agreements:
· For power consumption scaling for adaptation,
o (Working assumption) Scaling of SL BWP size adaptation in RX perspective
§ X MHz is (0.4 +0.6*(X-20)/80)*100 MHz
o Scaling for SL BWP size adaptation in TX perspective
§ No scaling
o Scaling for RX AP adaptation for FR 1
§ 2 RX is 0.7*4 Rx power
· Note that scaling for adaptation on other parameters is not precluded for power consumption model, and companies are encouraged to provide the assumptions in details.
Agreements:
· For power consumption level,
o Reuse three states of “Sleep” specified in TR38.840 including transition time/energy consumption
o (Working assumption) For “PSCCH/PSSCH RX”,
§ In non-PSFCH-slot (i.e., the number of PSCCH/PSSCH symbols is 13),
· the power consumption level is the same as that of “PDCCH+PDSCH”
o For power consumption level of “PSCCH/PSSCH TX”
§ In non-PSFCH-slot (i.e. the number of PSCCH/PSSCH symbols is 13),
· the power consumption level is the same as that of “UL” for long PUCCH or PUSCH
o For power consumption level of “1st SCI/2nd SCI RX”,
§ the power consumption level is [0.7]* power consumption level of “PSCCH/PSSCH RX”
o For power consumption level of “PSFCH TX”,
§ the power consumption level is [0.3]*power consumption level of “UL” for long PUCCH or PUSCH
o (Working assumption) For power consumption level of “PSFCH RX”,
§ the power consumption level is power consumption level of “PDCCH-only” for cross-slot scheduling
o For power consumption level of “S-SSB TX” (in 13 symbol duration),
§ the power consumption level is the same as power consumption level of “UL” for (long PUCCH or PUSCH)
o For power consumption level of “S-SSB RX”,
§ the power consumption level is [1.5]*power consumption level of “Uu SSB-processing”
o The power consumption level of “GNSS-processing” is 8
o When the synch reference source is gNB, reuse power consumption level of “Uu SSB processing”
o Power consumption level of “SL-CSI-RS processing” is not separately defined
· Note that power consumption level of other Power states is not precluded, and companies are encouraged to provide the assumptions in details.
Agreements:
· For evaluation metric, the followings are considered
o PRR
o PIR
o Power consumption reduction ratio = (power consumption for baseline scheme with Rel-16 Mode 2 resource allocation (i.e. full sensing) - power consumption for proposed scheme)/power consumption for baseline scheme with Rel-16 Mode 2 resource allocation (i.e. full sensing)
· Note that power consumption for baseline scheme with Rel-16 Mode 2 resource allocation (i.e. full sensing) and the power consumption for the proposed scheme are evaluated under the same evaluation assumptions.
R1-2006169 On Resource Allocation Enhacements Samsung
A placeholder – no plan to treat it in this meeting
R1-2005295 Power consumption reduction for sidelink resource allocation FUTUREWEI
R1-2005310 Discussion on resource allocation for power saving ZTE, Sanechips
R1-2005403 Resource allocation for sidelink power saving vivo
R1-2005500 Discussion of sidelink resource allocation for power saving Nokia, Nokia Shanghai Bell
R1-2005545 Considerations on partial sensing in NR-V2X Fujitsu
R1-2005587 Resource allocation for power saving Sony
R1-2005642 Power saving techniques for sidelink MediaTek Inc.
R1-2005691 Discussion on resource allocation for power saving CATT
R1-2005748 Discussion on resource allocation for power saving LG Electronics
R1-2005762 Views on resource allocation for power saving NEC
R1-2005839 Sidelink resource allocation for Power saving Lenovo, Motorola Mobility
R1-2005896 Sidelink enhancements for UE power saving Intel Corporation
R1-2006009 Power saving mechanisms for NR SL OPPO
R1-2006170 On Resource Allocation for Power Saving Samsung
R1-2006183 Sidelink resource allocation for power saving InterDigital, Inc.
R1-2006230 Discussion on resource allocation for power saving CMCC
R1-2006267 Discussion on sidelink resource allocation for power saving Spreadtrum Communications
R1-2006401 Sidelink resource allocation to reduce power consumption Huawei, HiSilicon
R1-2006444 Resource allocation mechanisms for power saving Ericsson
R1-2006507 On Resource Allocation for Power Saving Apple
R1-2006625 Discussion on resource allocation for power saving Xiaomi
R1-2006747 Discussion on sidelink resource allocation for power saving NTT DOCOMO, INC.
R1-2006828 Power Savings for Sidelink Qualcomm Incorporated
R1-2006860 Considerations on partial sensing in NR V2X CAICT
R1-2006873 Resource allocation for power saving with partial sensing in NR sidelink enhancement ITL
R1-2006878 Sidelink Resource Allocation to Reduce Power Consumption ROBERT BOSCH GmbH
Focusing on high-level concepts for mode 2 reliability and latency enhancements
R1-2005255 Inter-UE coordination in sidelink resource allocation Huawei, HiSilicon
R1-2005296 Views on resource allocation enhancements for sidelink communication FUTUREWEI
R1-2005404 Discussion on mode-2 enhancements vivo
R1-2005501 Discussion of sidelink resource allocation mode 2 enhancements Nokia, Nokia Shanghai Bell
R1-2005537 Resource Allocation Enhancements for Mode 2 Fraunhofer HHI, Fraunhofer IIS
R1-2005546 Considerations on inter-UE coordination for mode 2 enhancements Fujitsu
R1-2005588 High-level concepts for mode 2 enhancements Sony
R1-2005612 Considerations on Mode 2 Latency Enhancement ITRI
R1-2005645 Discussion on Mode 2 enhancements MediaTek Inc.
R1-2005692 Discussion on feasibility and benefits for mode 2 enhancements CATT
R1-2005749 Discussion on feasibility and benefits for mode 2 enhancements LG Electronics
R1-2005763 Views on feasibility and benefits for mode 2 enhancements NEC
R1-2005774 Feasibility and benefits for mode 2 enhancements TCL Communication Ltd.
R1-2005840 Sidelink resource allocation for Reliability enhancement Lenovo, Motorola Mobility
R1-2005897 On feasibility and benefits of sidelink enhancements targeting Mode 2 reliability and latency Intel Corporation
R1-2005903 Inter-UE coordination for enhanced resource allocation Mitsubishi Electric RCE
R1-2005961 Inter-UE coordination in mode-2 ZTE, Sanechips
R1-2006010 Discussion on feasibility and benefits of mode 2 enhancements OPPO
R1-2006171 On Feasibility and Benefits for Mode2 Enhancements Samsung
R1-2006184 NR SL Mode 2 enhancement for reliability improvement InterDigital, Inc.
R1-2006231 Discussion on reliability and latency enhancements for mode-2 resource allocation CMCC
R1-2006268 Discussion on feasibility and benefit of mode 2 enhancements Spreadtrum Communications
R1-2006445 Feasibility and benefits of mode 2 enhancements for inter-UE coordination Ericsson
R1-2006508 Mode 2 Resoruce Allocation with Inter-UE Coordination Apple
R1-2006537 Mode 2 enhancements in sidelink Panasonic Corporation
R1-2006587 Discussion on V2X mode 2 enhancements ASUSTeK
R1-2006626 Discussion on Mode 2 enhancement for enhanced reliability and reduced latency Xiaomi
R1-2006748 Discussion on sidelink resource allocation for reliability and latency enhancements NTT DOCOMO, INC.
R1-2006829 Reliability and Latency Enhancements for Mode 2 Qualcomm Incorporated
R1-2006876 Sidelink Resource Allocation Enhancements ROBERT BOSCH GmbH
R1-2006922 On Resource Allocation Mode 2 Enhancement for NR Sidelink Convida Wireless
[102-e-NR-SL_enh-02] – Seungmin (LGE)
Email discussion/approval using the summary as a starting point, focusing on high-level concepts for 8.11.2.2
R1-2007412 Summary for AI 8.11.2.2 Feasibility and benefits for mode 2 enhancements Moderator (LG Electronics)
Deadline extended to 8/28 (due to late kick-off) à extended to 8/31
Decision: As per email decision posted on Sept. 2nd, no agreements as the group couldn't converge on something to be further studied/discussed. The latest proposals are summarized in R1-2007412.
R1-2005405 Discussion on sidelink DRX vivo
R1-2005611 Discussion on enhancement for NR V2X ITRI
R1-2005613 Discussion on collaboration among sidelink UEs for mode-2 resource allocation ITRI
R1-2005841 Discussion on potential sidelink DRX impacts in RAN1 Lenovo, Motorola Mobility
R1-2005962 Potential impact of DRX enhancement to RAN1 discussion ZTE, Sanechips
R1-2006011 Inter-UE coordination in mode 2 of NR sidelink OPPO
R1-2006172 On Sidelink Issues and RAN1 Impacts Samsung
R1-2006402 Physical layer impacts of sidelink DRX Huawei, HiSilicon
R1-2006446 Other resource allocation topics Ericsson
R1-2006618 On multi-carrier operation for SL InterDigital, Inc.
Please refer to RP-201516 for detailed scope of the WI
R1-2008186 On Sidelink Enhacement Work Item Samsung
R1-2007832 Discussion on sidelink evaluation methodology for power saving CATT
· Proposal 1: For power consumption levels in FR1,
o For PSCCH/PSSCH Rx in non-PSFCH slot,
§ The power consumption level is 0.936*power consumption level of “PDCCH+PDSCH”, which revised the working assumption in RAN1#102e-meeting.
o For PSCCH/PSSCH Rx in PSFCH slot,
§ The power consumption level is 0.744*power consumption level of “PDCCH+PDSCH”.
o For PSCCH/PSSCH Tx in PSFCH slot,
§ The power consumption level is 0.785*power consumption level of “UL” for long PUCCH or PUSCH.
o For PSFCH Tx only,
§ The power consumption level is 0.354*power consumption level of “UL” for long PUCCH or PUSCH.
o PSCCH/PSSCH Rx and PSFCH Rx
§ The power consumption level is 0.872*power consumption level of “PDCCH+PDSCH”.
o PSCCH/PSSCH Rx and PSFCH Tx
§ The power consumption level is sum of the levels of “PSCCH/PSSCH Rx in PSFCH slot” and “PSFCH Tx”.
o PSCCH/PSSCH Tx and PSFCH Rx
§ The power consumption level is sum of the levels of “PSCCH/PSSCH Tx in PSFCH slot” and “PSFCH Rx”.
o PSCCH/PSSCH Tx and PSFCH Tx
§ The power consumption level is 0.892*power consumption level of “UL” for long PUCCH or PUSCH.
o For 1st SCI/2nd SCI Rx in PSFCH slot
§ The power consumption level is [0.7]* power consumption level of “PSCCH/PSSCH RX in PSFCH slot”
o For 1st SCI/2nd SCI Rx and PSFCH Rx
§ The power consumption level is sum of the levels of “1st SCI/2nd SCI Rx in PSFCH slot” and “PSFCH Rx”.
o For 1st SCI/2nd SCI Rx and PSFCH Tx
§ The power consumption level is sum of the levels of “1st SCI/2nd SCI Rx in PSFCH slot” and “PSFCH Tx”.
· Proposal 2: Cluster-based vehicle dropping (vehicle dropping option C for highway scenario in 37.885) should be studied and evaluated in Rel-17 sidelink enhancement.
· Proposal 3: The pedestrian UE dropping in TR36.885 should be a starting point for system evaluation in Rel-17 sidelink enhancement.
· Proposal 4: In order to evaluate unicast communication, one additional unicast pairs determining method should be support:
o The unicast pairs are two vehicles neighbored within same lane.
· Proposal 5: The traffic model for pedestrian UEs in TR36.885 should be a starting point in Rel-17 sidelink enhancement, and details are provided as following:
o Periodic traffic with inter-packet arrival time: 1000ms
o Packet size: fixed 300Bytes
o Latency requirement: 100ms
Decision: The document is noted.
R1-2007614 Sidelink evaluation methodology update for power saving Huawei, HiSilicon
R1-2007621 Discussion of remaining issues for sidelink evaluation methodology update for power saving Nokia, Nokia Shanghai Bell
R1-2007687 Discussion on sidelink evaluation methodology vivo
R1-2007894 Discussion on remaining aspects of sidelink evaluation methodology update for power saving LG Electronics
R1-2008187 On Sidelink Evaluation Methodology Updates for Power Saving Samsung
R1-2008238 Discussion on evaluation methodology for SL power saving OPPO
R1-2008445 Discussion on Sidelink Power Consumption Model Apple
R1-2008877 Analysis on remaining issues for sidelink evaluation methodology ZTE Corporation, Sanechips
R1-2008916 Discussion on sidelink evaluation methodology update for power saving Lenovo, Motorola Mobility
R1-2008970 Remaining issues for sidelink evaluation methodology MediaTek Inc.
R1-2008997 Remaining issues for sidelink evaluation methodology update for power saving Intel Corporation
R1-2009036 Discussion on remaining issues of sidelink evaluation methodology update Xiaomi
R1-2009071 Remaining evaluation assumptions and methodology for power saving Ericsson
R1-2009120 V2X evaluation methodology and channel model updates InterDigital, Inc.
R1-2009192 Remainig issues on sidelink evaluation methodology for power saving NTT DOCOMO, INC.
R1-2009271 Evaluation Methodology for Power Saving in Sidelink Qualcomm Incorporated
[103-e-NR-Sidelink-Enh-01] – Seungmin (LGE)
Email discussion/approval for remaining issues for sidelink evaluation methodology update for power saving
R1-2009787 Feature lead summary for AI 8.11.1 Remaining issues for sidelink evaluation methodology update for power saving Moderator(LG Electronics)
Decisions from GTW sessions:
Agreements:
Confirm the following agreement with red changes:
Agreements:
Remove the square brackets in the following agreements with red-colored clarification.
Agreements:
Support following three states for V2P/P2V links.
Agreements:
For two UEs are in the same street in V2P/P2V links, reuse the probability of LOS and NLOSv states for Urban case specified in TR 37.885 (see below)
Agreements
For V2P/P2V links, reuse “additional vehicle blockage loss” specified in TR 37.885 (see below).
|
When a link is in NLOSv, additional vehicle blockage loss is added as follows: · The blocker height is the vehicle height which is randomly selected out of the three vehicle types according to the portion of the vehicle types in the simulated scenario. · The additional blockage loss is max {0 dB, a log-normal random variable}. · Case 1: Minimum antenna height value of TX and RX > Blocker height ü No additional blockage loss · Case 2: Maximum antenna height value of TX and RX < Blocker height ü Mean: 9 + max(0, 15*log10(d)-41) dB, standard deviation: 4.5 dB · Case 3: Otherwise ü Mean: 5 dB + max(0, 15*log10(d)-41), standard deviation: 4 dB |
Agreements:
For V2P/P2V links, reuse the fast fading parameters of V2V link specified in TR 37.885.
· Note: this does not imply that a Ped UE is required to use the same antenna configuration of a Veh UE
Agreements:
For the public safety and commercial use cases, reuse the parameters of “Reference system deployments” specified in Section A.2.1.1 of TR 36.843 with following modification:
· Carrier frequency:
o Include 3.5 GHz for commercial use case (optional)
· System bandwidth:
o Include 40 MHz for commercial use case (optional) and 20 MHz dedicated spectrum for out-of-coverage scenarios (optional)
· “eNB” is replaced by “gNB”
· FFS any refinement/variation is necessary, e.g., 19 vs. 7 sites, etc.
Agreements:
For the public safety and commercial use cases, reuse the parameters of “Channel models” specified in Section A.2.1.2 of TR 36.843 with following modification:
· Each component of channel model reuses what is specified in TR 38.901.
Decision: As per email decision posted on Nov.12th,
Agreement:
· For the layout for public safety and commercial use cases, support “7 macro sites with 3 cells per site in the layout”
Agreements:
· For public safety use case, at least following layout option is supported:
Agreements:
· For public safety and commercial use cases, at least following option is supported for UE RF parameters:
o Reuse the number of TX AP, the number of RX AP, antenna gain for P-UE specified in TR 37.885.
Agreement:
· For public safety and commercial use cases, one OFDM symbol of NR SL slot is used for AGC
Agreements:
For public safety and commercial use cases, at least performance metrics for communication specified in A2.1.4.2 of TR 36.843 are reused with following modification:
Agreement:
· For public safety and commercial use cases, reuse in-band emission model used for NR V2X specified in section 6.4E.2.4 in TS 38.101
Decision: As per email decision posted on Nov.13th,
Agreements:
· For the channel model for P2P link,
· Note that the intention of channel model above is at least for modeling the interference generation in P2P link. The modeling P2P link is not applied to the scenario of V2P only, optionally applied or not to the scenario of P2V only, but applied to the scenario of combination of V2P and P2V.
Agreements:
· For the fast fading parameters for P2P link, reuse fast fading parameters of V2V/V2P/P2V links.
· Note that the intention of channel model above is at least for modeling the interference generation in P2P link. The modeling P2P link is not applied to the scenario of V2P only, optionally applied or not to the scenario of P2V only, but applied to the scenario of combination of V2P and P2V.
Agreements:
· For P2V link, at least following traffic model is supported:
o Option 1: Traffic model for P-UE’s transmission specified in TS 36.885
§ The message size is fixed at 300 bytes and transmission frequency is 1 Hz
§ ‘100ms’ latency requirement
o Option 4: Aperiodic Model 1 specified in TR37.885 with following changes:
§ Inter-packet arrival time: 250 ms + an exponential random variable with the mean of 250 ms
§ Packet size: Uniformly random in the range between 200 bytes and 800 bytes with the quantization step of 200 bytes
§ Latency requirement: 250 ms or 100 ms
Agreements:
· For commercial use case, at least following option is supported for traffic model:
o Option 7: Periodic traffic model 3 specified in TR 37.885
Agreements:
· For the pedestrian UE dropping in V2X evaluation, reuse those specified in TR 36.885.
o Support that total number of pedestrian UEs is 1000 as optional
Agreements:
· For V2P link, V2V traffic model and the following options for traffic model are supported. Companies declare which traffic model is used for their V2P evaluation.
o Option 7: Periodic Model 2 specified in TR 37.885 with following change:
§ Inter-packet arrival time: 500ms
§ Latency requirement: 500 ms or 100 ms
o Option 8: Aperiodic Model 1 specified in TR 37.885 with following change:
§ Inter-packet arrival time: 250 ms + an exponential random variable with the mean of 250 ms
§ Packet size: Uniformly random in the range between 200 bytes and 800 bytes with the quantization step of 200 bytes
§ Latency requirement: 250 ms or 100 ms
R1-2007878 Discussion on enhancement for NR V2X Mode 2 ITRI
R1-2008188 On Resource Allocation Enhacements Samsung
R1-2007615 Sidelink resource allocation to reduce power consumption Huawei, HiSilicon
· Proposal 1: Configure specific resource pools for NR partial sensing/random selection, and for full sensing.
o Further consideration on conditions to enable random selection/partial sensing in a full-sensing resource pool.
· Proposal 2: NR partial sensing, enhanced based on the LTE-V mechanism, needs to take into account the full set of NR sidelink periodicities {(1..99), 100, 200, 300, 400, 500, 600, 700, 900, 1000} ms provided by the resource pool.
· Proposal 3: NR partial sensing, in order to avoid failure detection of SCIs in slots for partial sensing for a given traffic periodicity as provided by reservation period of the resource pool, should support monitoring multiple slots for partial sensing per traffic periodicity in determining whether to exclude a candidate resource.
· Proposal 4: NR partial sensing, based on the LTE-V mechanism, can be enhanced by introducing a short sensing window before the first selected candidate resource to take into account aperiodic traffic reservations.
· Proposal 5: Support re-evaluation and pre-emption check for UEs operating power saving.
· Proposal 6: For NR sidelink, enhance LTE-V random selection for high QoS requirement traffic.
o Allow a NR sidelink random selection UE to pre-empt the resources reserved by a sensing-based UE.
· Proposal 7: Sidelink congestion control defined in Rel-16 needs adaptation for sidelink power saving operation in Rel-17, e.g. with partial sensing or sidelink DRX.
Decision: The document is noted.
R1-2007688 Resource allocation for sidelink power saving vivo
· Proposal 1: The NR SL power saving mechanism should support the following cases: power-limited UE in the TX side only (e.g., P2V), in the RX side only (e.g., V2P), and in both TX and RX sides (e.g., for public safety or commercial D2D).
· Proposal 2: The design of power saving mechanism should consider different reception capabilities of UE:
o Capability #1: UE does not support sidelink reception.
o Capability #2: UE supports receiving PSCCH on sidelink
o Capability #3: UE supports receiving PSFCH on sidelink
o Capability #4: UE supports the reception of PSCCH, PSSCH, (and PSFCH)
· Proposal 3: For UE that support capability #4, it is beneficial for that UE to support SL measurement (e.g., RSRP or CBR/CR).
· Proposal 4: The mechanisms of power saving enhancement for mode-2 should focus on reducing power consumption of Sensing, PSSCH reception and PSFCH transmission.
· Proposal 5: To reduce the collision possibility caused by aperiodic resource allocation, a short term partial sensing window before the resource selection window should be introduced for NR partial sensing mechanism.
· Proposal 6: Support periodic partial sensing with multiple sensing window periods based on resource reservation periods configured per resource pool.
· Proposal 7: Higher priority is assigned to the resources selected by a power-limited UE, to preserve these selected resources from being pre-empted by UEs without battery constrain.
· Proposal 8: SL pathloss based OLPC for PSFCH should be supported for power-limited UE.
· Proposal 9: Longer PSFCH period should be studied for power-limited UE.
· Proposal 10: Taking discontinuous reception time of Rx UE into account to enhance resource selection mechanism for V2P and D2D communication.
· Proposal 11: RAN1 should study the interaction between partial sensing and SL DRX mechanisms, e.g., coordination between partial sensing/selection window and SL DRX pattern.
· Proposal 12: RAN1 should study the impact of SL DRX on SL measurement and reporting.
Decision: The document is noted.
R1-2009193 Discussion on sidelink resource allocation for power saving NTT DOCOMO, INC.
· Proposal 1: For power saving in Rel-17 NR SL enhancement, the following types of UEs are assumed.
o UE incapable of data reception
o UE capable of data reception
· Proposal 2:
o An LS is sent to RAN2 to inform them of the following.
§ RAN1 assumes that this WI supports both of UE capable of data reception with power saving and UE incapable of data reception with power saving.
§ RAN1 asks whether to consider DRX in resource identification to report candidate resources to MAC layer.
o RAN1 firstly focuses on UE incapable of data reception.
§ After RAN2 decisions on DRX mechanism, some modifications are discussed for UE capable of data reception if necessary.
· Proposal 3: A resource pool can be configured with multiple types of resource allocation mechanisms.
· Proposal 4: Partial sensing is supported with separate determination of sensing target for periodic reservation and aperiodic reservation.
o For periodic reservation, LTE-SL partial sensing is reused with some update.
§ Y slots are set to candidate resources.
§ Resources determined based on the Y slots and periodicities possible to be indicated are monitored.
§ FFS: how to update from LTE-SL mechanism.
o For aperiodic reservation, resources within [y1-31, n-Tproc,0) is monitored, where y1 is the first slot index within Y slots of selection candidates in partial sensing.
· Proposal 5:
o For periodic reservation, LTE partial sensing is enhanced to consider shorter periodicities.
o The following options are considered for the enhancement.
§ Option 1: Restrict available periodicities in the resource pool configured with partial sensing
§
Option 2: 
is
determined based on periodicities configured in the resource pool
§ Option 3: Sensing target is the last N periods per periodicity
§ Other options are not precluded.
· Proposal 6: Resource allocation to transmit to a power saving UE is enhanced for less PSFCH transmission occasions at the UE.
· Proposal 7: Resource allocation at a power saving UE is enhanced for less PSFCH reception occasions at the UE.
· Proposal 8: NR re-evaluation and pre-emption are enhanced for less monitoring slots at partial sensing UE.
· Proposal 9: LTE random selection is enhanced to reduce resource collisions.
· Proposal 10: Random selection is used with HARQ feedback = disabled.
Decision: The document is noted.
R1-2007553 Power consumption reduction for sidelink resource allocation FUTUREWEI
R1-2007622 Discussion of resource allocation for power saving Nokia, Nokia Shanghai Bell
R1-2007787 Considerations on partial sensing in NR V2X Fujitsu
R1-2007833 Discussion on resource allocation for power saving CATT
R1-2007879 Discussion on sidelink resource allocation for power saving ITRI
R1-2007892 Resource allocation for power saving TCL Communication Ltd.
R1-2007895 Discussion on resource allocation for power saving LG Electronics
R1-2008031 Discussion on resource allocation for power saving CMCC
R1-2008098 Discussion on sidelink resource allocation for power saving Spreadtrum Communications
R1-2008189 On Resource Allocation for Power Saving Samsung
R1-2008239 Power saving mechanism in NR sidelink OPPO
R1-2008373 Discussion on sidelink resource allocation for power saving Sony
R1-2008446 Discussion on Resource Allocation for Power Saving Apple
R1-2008817 NR Sidelink Resource Allocation for UE Power Saving Fraunhofer IIS, Fraunhofer HHI
R1-2008836 Discussion on Sidelink Resource Allocation for Power Saving Panasonic Corporation
R1-2008878 Discussion on resource allocation for power saving ZTE Corporation, Sanechips
R1-2008917 Sidelink resource allocation for Power saving Lenovo, Motorola Mobility
R1-2008950 Discussion on resource allocation for power saving NEC
R1-2008971 Resource allocation for sidelink power saving MediaTek Inc.
R1-2008998 Potential sidelink enhancements for UE power saving Intel Corporation
R1-2009021 Discussion on resource allocation for power saving ETRI
R1-2009037 Discussion on sidelink resource allocation for power saving Xiaomi
R1-2009072 Resource allocation mechanisms for power saving Ericsson
R1-2009079 Considerations on partial sensing in NR V2X CAICT
R1-2009121 Sidelink resource allocation for power saving InterDigital, Inc.
R1-2009128 Sidelink resource allocation to reduce power consumption ROBERT BOSCH GmbH
R1-2009138 Discussion on resource allocation for power saving Sharp
R1-2009161 On Resource Allocation Power Saving Enhancement for NR Sidelink Convida Wireless
R1-2009222 Resource allocation for power saving with partial sensing in NR sidelink enhancement ITL, KRRI
R1-2009272 Power Savings for Sidelink Qualcomm Incorporated
R1-2009287 Views on power saving for NR sidelink enhancement KT Corp.
[103-e-NR-Sidelink-Enh-02] – Kevin (OPPO)
Email discussion/approval for resource allocation for power saving
R1-2009584 FL summary for AI 8.11.2.1 – resource allocation for power saving Source: Moderator (OPPO)
Decisions from GTW session on Nov.11th,
Conclusion
Agreements:
· Partial sensing based RA is supported as a power saving RA scheme
o FFS details
· Random resource selection is supported as a power saving RA scheme
o FFS any changes or enhancement
o FFS on conditions to apply random resource selection
Agreements:
· In R17, a SL Mode 2 Tx resource pool can be (pre-)configured to enable full sensing only, partial sensing only, random resource selection only, or any combination(s) thereof
o FFS details, including usage, potential restrictions, whether/how any enhancement or condition is needed for the coexistence of full sensing and power saving RA scheme(s) in a same resource pool, etc.
Decision: As per email decision posted on Nov.13th,
Agreements:
Agreements:
· Further study congestion control based on CBR and CR for power saving RA schemes
o Identify necessary changes from R16 CBR/CR (if any), including transmission resource selection and transmission parameters that can be adjusted and applicable to power savings RA schemes
o Note: this is not intended to require all UEs to perform sensing for the purpose of CBR measurement
R1-2008879 Inter-UE coordination in mode-2 ZTE Corporation, Sanechips
Decision: The document is noted.
R1-2008999 Analysis of potential sidelink enhancements targeting Mode 2 reliability and latency Intel Corporation
Decision: The document is noted.
R1-2009273 Reliability and Latency Enhancements for Mode 2 Qualcomm Incorporated
Decision: The document is noted.
R1-2007554 Views on resource allocation enhancements for sidelink communication FUTUREWEI
R1-2007616 Inter-UE coordination in sidelink resource allocation Huawei, HiSilicon
R1-2007623 Discussion of feasibility and benefits for mode 2 enhancements Nokia, Nokia Shanghai Bell
R1-2007689 Discussion on mode-2 enhancements vivo
R1-2007771 Inter-UE Coordination Mode 2 Kyocera Corporation
R1-2007788 Considerations on inter-UE coordination for mode 2 enhancements Fujitsu
R1-2007834 Discussion on feasibility and benefits for mode 2 enhancements CATT
R1-2007880 Enhancement of Mode 2 Latency Performance ITRI
R1-2007893 Feasibility and benefits for mode 2 enhancements TCL Communication Ltd.
R1-2007896 Discussion on feasibility and benefits for mode 2 enhancements LG Electronics
R1-2008032 Discussion on reliability and latency enhancements for mode-2 resource allocation CMCC
R1-2008099 Discussion on feasibility and benefit of mode 2 enhancements Spreadtrum Communications
R1-2008190 On Feasibility and Benefits for Mode2 Enhancements Samsung
R1-2009319 Inter-UE coordination in mode 2 of NR sidelink OPPO (Revision of R1-2008240)
R1-2008374 Discussion on reliability and latency enhancements for mode 2 Sony
R1-2008447 Discussion on Inter-UE Coordination for Mode 2 Resource Allocation Apple
R1-2008499 Discussion on V2X mode 2 enhancements ASUSTeK
R1-2008757 Resource Allocation Enhancements for Mode 2 Fraunhofer HHI, Fraunhofer IIS
R1-2008820 Views on inter-UE coordination for mode 2 enhancements Zhejiang Lab
R1-2008861 Inter-UE coordination for enhanced resource allocation Mitsubishi Electric RCE
R1-2008892 Inter-UE coordination for mode 2 enhancement ITL
R1-2008918 Sidelink resource allocation for Reliability enhancement Lenovo, Motorola Mobility
R1-2008951 Discussion on feasibility and benefits for mode 2 enhancements NEC
R1-2008975 Discussion on Mode 2 enhancements MediaTek Inc.
R1-2009022 Discussion on feasibility and benefits for mode 2 enhancements ETRI
R1-2009038 Considerations on Mode 2 enhancement for enhanced reliability and reduced latency Xiaomi
R1-2009073 Feasibility and benefits of mode 2 enhancements for inter-UE coordination Ericsson
R1-2009122 NR SL Mode 2 enhancement for reliability improvement InterDigital, Inc.
R1-2009126 Mode 2 enhancements in sidelink Panasonic Corporation
R1-2009127 Discussion on sidelink mode-2 resource allocation enhancements ROBERT BOSCH GmbH
R1-2009139 Enhancements of resource allocation Mode 2 for NR sidelink Sharp
R1-2009162 On Resource Allocation Mode 2 Enhancement for NR Sidelink Convida Wireless
R1-2009194 Resource allocation for reliability and latency enhancements NTT DOCOMO, INC.
R1-2009291 Discussion on feasibility and benefits for NR Sidelink mode 2 enhancements CEWiT
R1-2009297 Views on feasibility and benefits for mode 2 enhancements KT Corp.
[103-e-NR-Sidelink-Enh-03] – Seungmin (LGE)
Email discussion/approval for feasibility and benefits for mode 2 enhancements
R1-2009788 Feature lead summary for AI 8.11.2.2 Feasibility and benefits for mode 2 enhancements Moderator(LG Electronics)
Decision: As per email decision posted on Nov.13th,
Conclusion:
Conclusion:
LS email approval till 11/17
R1-2009841 LS on Mode 2 enhancements in NR sidelink RAN1, LG Electronics
Decision: As per email decision posted on Nov.18th, the LS is approved.
R1-2007690 Discussion on sidelink DRX vivo
R1-2007881 Discussion on NR sidelink enhancements ITRI
R1-2007897 Discussion on physical layer design considering sidelink DRX operation LG Electronics
R1-2008191 On Sidelink Issues and RAN1 Impacts Samsung
R1-2008241 The effect of DRX on resource selection OPPO
R1-2008332 Physical layer impacts of sidelink DRX Huawei, HiSilicon
R1-2008448 Discussion on Sidelink DRX Apple
R1-2008500 Discussion on SL DRX impact on physical layer ASUSTeK
R1-2008758 Other Sidelink Aspects Impacting RAN1 Fraunhofer HHI, Fraunhofer IIS
R1-2008880 Potential impact of DRX enhancement to RAN1 discussion ZTE Corporation, Sanechips
R1-2008919 Discussion on potential sidelink DRX impacts in RAN1 Lenovo, Motorola Mobility
R1-2009039 Discussion on power saving and congestion control Xiaomi
R1-2009074 On the relationship between partial sensing and DRX Ericsson
R1-2009123 On multi-carrier and DRX operation for SL InterDigital, Inc.
Please refer to RP-202846 for detailed scope of the WI
R1-2101229 On Sidelink Enhacement Work Item Samsung
From AI5
[104-e-NR-R17-SL-LS-01] Email discussion regarding LS in R1-2100021, including a possible reply LS till 2/1 – Boyuan Zhang (ZTE)
R1-2102024 Summary of [104-e-NR-R17-SL-LS-01] regarding potential reply to LS in R1-2100021 Moderator (ZTE)
Decision: As per email posted on Feb 2nd, postpone the reply LS discussion till next e-meeting.
R1-2100722 V2X channel model and scenario updates GDCNI
R1-2101230 On Resource Allocation Enhancements Samsung
Including consideration of the impact of sidelink DRX, if any
R1-2100141 Power saving mechanism in NR sidelink OPPO
R1-2100205 Sidelink resource allocation to reduce power consumption Huawei, HiSilicon
R1-2100309 Considerations on partial sensing in NR V2X CAICT
R1-2100351 Discussion on resource allocation for power saving CATT, GOHIGH
R1-2101790 Resource allocation for sidelink power saving vivo (resp of R1-2100466)
R1-2100486 Power consumption reduction for sidelink resource allocation FUTUREWEI
R1-2100492 Discussion on resource allocation for power saving Zhejiang Lab
R1-2100517 Discussion on resource allocation for power saving LG Electronics
R1-2100538 Sidelink resource allocation for power saving Nokia, Nokia Shanghai Bell
R1-2100546 Resource allocation for power saving TCL Communication Ltd.
R1-2100612 Resource allocation for sidelink power saving MediaTek Inc.
R1-2100672 Design of sidelink power saving solutions Intel Corporation
R1-2100687 Resource allocation mechanisms for power saving Ericsson
R1-2100696 Discussion on Sidelink Resource Allocation for Power Saving Panasonic Corporation
R1-2100701 NR Sidelink Resource Allocation for UE Power Saving Fraunhofer HHI, Fraunhofer IIS
R1-2101788 Considerations on partial sensing and DRX in NR V2X Fujitsu (resp of R1-2100745)
R1-2100766 Sidelink resource allocation for Power saving Lenovo, Motorola Mobility
R1-2100801 Discussion on sidelink resource allocation for power saving Spreadtrum Communications
R1-2100870 Discussion on sidelink resource allocation for power saving Sony
R1-2100924 Discussion on sidelink power saving ZTE, Sanechips
R1-2100946 Discussion on resource allocation for power saving NEC
R1-2100962 Discussion on resource allocation for power saving Hyundai Motors
R1-2100981 Resource allocation for power saving InterDigital, Inc.
R1-2101060 Discussion on resource allocation for power saving CMCC
R1-2101086 Discussion on resource allocation for power saving ETRI
R1-2101097 Discussion on sidelink resource allocation for power saving Xiaomi
R1-2101231 On Resource Allocation for Power Saving Samsung
R1-2101357 Sidelink Resource Allocation for Power Saving Apple
R1-2101400 Discussion on Reduce Power Consumption for Sidelink ROBERT BOSCH GmbH
R1-2101422 On NR Sidelink Resource Allocation for Power Saving Convida Wireless
R1-2101485 Power Savings for Sidelink Qualcomm Incorporated
R1-2101550 Discussion on resource allocation for power saving Sharp
R1-2101572 Discussion on partial sensing and SL DRX impact ASUSTeK
R1-2101630 Discussion on sidelink resource allocation for power saving NTT DOCOMO, INC.
R1-2101663 Resource allocation for power saving with partial sensing in NR sidelink enhancement ITL
[104-e-NR-R17-SL-01] – Kevin (OPPO)
Email discussion on resource allocation for power saving
- 1st check point: Jan 28
- 2nd check point: Feb 2
- 3rd check point: Feb 4
R1-2101412 FL summary for AI 8.11.1.1 – resource allocation for power saving Moderator (OPPO)
Agreements:
· Random resource selection is applicable to both periodic and aperiodic transmissions
o FFS conditions for random resource selection
Conclusion:
· PSFCH reception is not included for Type A UE
· S-SSB reception is not included for Type A UE
· SL reception Type B is additionally added
o Type B: Same as Type A with an exception of performing PSFCH and S-SSB reception
· Note: the same conditions as in RAN1#103-e regarding the context of the discussion of Type A and Type D still apply (also applicable to type B)
Agreements:
In a resource pool (pre-)configured with at least partial sensing, if UE performs periodic-based partial sensing, at least when the reservation for another TB (when carried in SCI) is enabled for the resource pool and resource selection/reselection is triggered at slot n, it is up to UE implementation to determine a set of Y candidate slots within a resource selection window, where
· FFS condition(s) and timing(s) for which periodic-based partial sensing is performed by UE
· The resource selection window is [n+T1, n+T2]
o As a baseline, T1 and T2 are defined in the same way as in R16 NR-V2X according to step 1 [TS 38.214 Sec. 8.1.4]
o Further discuss whether or not to introduce a threshold to re-define T1 and T2 such that
§ T1 ≥ 0 (subject to processing time constraint Tproc, 1), and T2 ≤ remaining PDB
§ T2-T1 ≤ (pre-)configured threshold
· A minimum value for Y is (pre-)configured from a range of values, FFS details
· FFS any restriction to determine Y candidate slots (including its relationship with SL-DRX)
· FFS whether the resource selection window [n+T1, n+T2] should be confined within a set of periodic set of resources and its relationship with SL-DRX
· Note: The terminology “periodic-based partial sensing” is based on the “partial sensing” used in LTE-V and it is intended to be used for the design and discussion of partial sensing in Rel-17.
Agreements:
In a resource pool
(pre-)configured with at least partial sensing, if UE performs periodic-based
partial sensing, at least when the reservation for another TB (when carried in
SCI) is enabled for the resource pool and resource selection/reselection is
triggered at slot n, the UE monitors slots of at least one a set
of periodic sensing occasions, where a
periodic sensing occasion is a set of slots according to 
if tvSL is included in the set of Y candidate slots.
· Preserve is a periodicity value from the configured set of possible resource reservation periods allowed in the resource pool (sl-ResourceReservePeriodList). Down select to one:
o Option 1: Preserve corresponds to all values from the configured set sl-ResourceReservePeriodList
o Option 2: Preserve corresponds to a subset of values from the configured set sl-ResourceReservePeriodList
§ FFS how to determine the subset (e.g., by (pre-)configuration, UE determination)
o Option 3: Preserve is a common divisor among values in the configured set sl-ResourceReservePeriodList
o Option 4: FFS others
·
k equals tois selected according to (down select to one)
o Option 1: Only the most recent sensing occasion within sensing window for a given reservation periodicity before the resource (re)selection trigger or the
set of Y candidate slots subject to processing time restriction
o Option 2: The two most recent sensing occasions within sensing window for a given reservation periodicity before the resource (re)selection trigger or the
set of Y candidate slots subject to processing time restriction
o Option 3: All possible
sensing occasions after 
o Option 4: Only one periodic sensing occasion for one reservation period. The k value is up to UE implementation. Max value for k is (pre-)configured.
o Option 5: k is (pre-)configured, including multiple values
o Option 6: (pre-)configuration of a bitmap, same as in LTE-V
o Option 7: FFS others
· FFS relationship between periodic sensing occasions and SL-DRX
· FFS condition(s) and timing(s) for which periodic-based partial sensing is performed by UE
· Note: companies are encouraged to show performance data for the down selections
Agreements:
· In a resource pool (pre-)configured with at least partial sensing, if UE performs contiguous partial sensing and resource (re-)selection is triggered in slot n, support the following option:
o Option 1: For the purpose of resource (re-)selection, the UE monitors slots between [n+TA, n+TB] and performs identification of candidate resources, in or after slot n+TB, based on all available sensing results, including periodic-based partial sensing results (if applicable).
§ FFS TA, TB (including the possibility of equal to zero, positive or negative) and remaining details (in particular, whether there should be exclusion of slots, changes in TA/TB values for different purposes, etc.)
§ FFS whether n can be replaced by e.g., index of some of Y candidate slots
o FFS condition(s) in which contiguous partial sensing is performed by UE
o FFS interaction with SL-DRX, if any
o FFS interaction with periodic-based partial sensing, if any
o Other options are not precluded
o Note: This option is not to replace random resource selection only without sensing or re-evaluation and pre-emption checking
R1-2100047 Views on resource allocation enhancements for sidelink communication FUTUREWEI
R1-2100142 Inter-UE coordination in mode 2 of NR sidelink OPPO
R1-2101941 Inter-UE coordination in sidelink resource allocation Huawei, HiSilicon (rev of R1-2100206)
R1-2100352 Discussion on feasibility and benefits for mode 2 enhancements CATT, GOHIGH
R1-2101911 Discussion on mode-2 enhancements vivo (rev of R1-2101791, rev of R1-2100467)
R1-2100493 Inter-UE coordination for mode 2 Zhejiang Lab
R1-2101786 Discussion on feasibility and benefits for mode 2 enhancements LG Electronics (rev of R1-2100518)
R1-2100539 Inter-UE coordination in mode 2 sidelink resource allocation Nokia, Nokia Shanghai Bell
R1-2100547 Feasibility and benefits for mode 2 enhancements TCL Communication Ltd.
R1-2101926 Discussion on Mode 2 enhancements MediaTek Inc. (rev of R1-2100606)
R1-2100673 On feasibility and benefits of inter-UE coordination for sidelink mode-2 design Intel Corporation
R1-2101804 Feasibility and benefits of mode 2 enhancements for inter-UE coordination Ericsson (rev of R1-2100688)
R1-2100702 Resource Allocation Enhancements for Mode 2 Fraunhofer HHI, Fraunhofer IIS
R1-2100746 Considerations on inter-UE coordination for mode 2 enhancements Fujitsu
R1-2100767 Sidelink resource allocation for Reliability enhancement Lenovo, Motorola Mobility
R1-2100802 Discussion on feasibility and benefit of mode 2 enhancements Spreadtrum Communications
R1-2100828 Inter-UE coordination for enhanced resource allocation Mitsubishi Electric RCE
R1-2100871 Discussion on reliability and latency enhancements for mode 2 Sony
R1-2100925 Discussion on inter-UE coordination ZTE, Sanechips
R1-2100947 Discussion on feasibility and benefits for mode 2 enhancements NEC
R1-2100963 Discussion on feasibility and benefits for mode 2 enhancements Hyundai Motors
R1-2100982 On inter-UE coordination for Mode 2 enhancement InterDigital, Inc.
R1-2101004 Mode 2 enhancements in sidelink Panasonic Corporation
R1-2101061 Discussion on reliability and latency enhancements for mode-2 resource allocation CMCC
R1-2101087 Discussion on feasibility and benefits for mode 2 enhancements ETRI
R1-2101098 Feasibility and benefits for mode2 enhancements Xiaomi
R1-2101232 On Feasibility and Benefits for Mode2 Enhancements Samsung
R1-2101358 Inter-UE Coordination for Mode 2 Resource Allocation Apple
R1-2101401 Discussion on Sidelink Mode-2 Resource Allocation Enhancements ROBERT BOSCH GmbH
R1-2101409 Inter-UE coordination for mode 2 enhancement ITL
R1-2101423 On NR Sidelink Resource Allocation Mode 2 Enhancement Convida Wireless
R1-2101910 Reliability and Latency Enhancements for Mode 2 Qualcomm Incorporated (rev of R1-2101486)
R1-2101551 Discussion on feasibility and benefits for mode 2 enhancements Sharp
R1-2101574 Discussion on V2X mode 2 enhancements ASUSTeK
R1-2101631 Resource allocation for reliability and latency enhancements NTT DOCOMO, INC.
R1-2101647 Feasibility and benefits for NR Sidelink mode 2 enhancements CEWiT
[104-e-NR-R17-SL-02] – Seungmin (LGE)
Email discussion on feasibility and benefits for mode 2 enhancements
- 1st check point: Jan 28
- 2nd check point: Feb 2
- 3rd check point: Feb 4
R1-2102268 Feature lead summary for AI 8.11.1.2 Feasibility and benefits for mode 2 enhancements Moderator (LG Electronics) (rev of R1-2102167)
Conclusion:
Further discuss the detailed observations (starting from the FL’s summary)
Agreements: Enclose following contents as an attachment of LS
=============================================================================
RAN1 has studied and evaluated schemes of inter-UE coordination in the following categories:
ü Type A: UE-A sends to UE-B the set of resources preferred for UE-B’s transmission
− e.g., based on its sensing result
ü Type B: UE-A sends to UE-B the set of resources not preferred for UE-B’s transmission
− e.g., based on its sensing result and/or expected/potential resource conflict
ü Type C: UE-A sends to UE-B the set of resources where the resource conflict is detected
Observations from evaluation results are summarized below. Note that the detailed evaulations for coordination schemes may not be fully aligned among companies. The details of the above schemes may also be different among companies in the evaluation. As a result, the observations drawn may be specific to the corrpresonding evaluated schemes with the assumed evaluation assumptions.
Observations from evaluation results w/ signaling overhead and latency for the inter-UE coordination scheme:
· Type A
o Periodic traffic
§ When UE-A sends to UE-B the set of resources used for UE-B’s transmission,
o Source 1 (R1-2101941) observed that their coordination scheme using the Type A-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast
§ When UE-A sends to UE-B the set of resources preferred for UE-B’s transmission,
o Source 1 (R1-2101941) observed that their coordination scheme using the Type A-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast
o Source 5 (R1-2100925) observed that their coordination scheme using the Type A-like resource is beneficial compared to Rel-16 Mode 2 RA for broadcast
o Source 6 (R1-2101911) observed that their coordination scheme using the Type A-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast under the scenario where UL transmission can overlap with SL transmission/reception
o Source 2 (R1-2100673) observed that their coordination scheme using the Type A-like resource is not beneficial compared to Rel-16 Mode 2 RA for unicast
o Source 3 (R1-2100746) observed that their coordination scheme using the Type A-like resource is not beneficial compared to Rel-16 Mode 2 RA for groupcast with SL HARQ-ACK feedback Option 1
o Aperiodic traffic
§ When UE-A sends to UE-B the set of resources used for UE-B’s transmission,
o Source 1 (R1-2101941) observed that their coordination scheme using the Type A-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast
o Source 2 (R1-2100673) observed that PRR loss of their coordination scheme using the Type A-like resource is shown compared to Rel-16 Mode 2 RA for unicast
§ When UE-A sends to UE-B the set of resources preferred for UE-B’s transmission,
o Source 1 (R1-2101941) observed that their coordination scheme using the Type A-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast
o Source 6 (R1-2101911) observed that their coordination scheme using the Type A-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast under the scenario where UL transmission can overlap with SL transmission/reception
· Type B
o Periodic traffic
§ Source 9 (R1-2101926) observed that their coordination scheme using the Type B-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast
o Aperiodic traffic
§ Source 12 (R1-2101804) observed that their coordination scheme using the Type B-like resource is beneficial compared to Rel-16 Mode 2 RA for groupcast
· Type C
o Periodic traffic
§ Source 3 (R1-2100746) and Source 13 (R1-2101910) observed that their coordination scheme using the Type C-like resource is beneficial compared to Rel-16 Mode 2 RA for groupcast with SL HARQ-ACK feedback Option 1
· Type C
o Aperiodic traffic
§ Source 2 (R1-2100673), Source 3 (R1-2100746), Source 12 (R1-2101804), and Source 13 (R1-2101910) observed that their coordination scheme using the Type C-like resource is beneficial compared to Rel-16 Mode 2 RA for groupcast with SL HARQ-ACK feedback Option 1
· Combination of Type B and C
o Aperiodic traffic
§ Source 12 (R1-2101804) observed that their coordination scheme using a combination of Type B-like and C-like resources is beneficial compared to Rel-16 Mode 2 RA, Type B-like resource, and Type C-like resource, respectively for groupcast
§ Source 13 (R1-2101910) observed that their coordination scheme using a combination of Type B-like and C-like resources is beneficial compared to Rel-16 Mode 2 RA, Type B-like resource, and Type C-like resource, respectively for groupcast with SL HARQ-ACK feedback Option 1
· Both signaling overhead and latency are considered for Type C-like resource, but only latency is considered for Type B-like resource
Observations from evaluation results w/o signaling overhead and/or latency for the inter-UE coordination scheme:
· W/o signaling overhead, w/ latency
o Type A
§ Periodic traffic
o When UE-A sends to UE-B the set of resources preferred for UE-B’s transmission,
§ Source 7 (R1-2100352) observed that their coordination scheme using the Type A-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast
§ Aperiodic traffic
o When UE-A sends to UE-B the set of resources preferred for UE-B’s transmission,
o Type B
§ Periodic traffic
o Source 7 (R1-2100352) and Source 10 (R1-2100142) observed that their coordination scheme using the Type B-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast
§ Source 10 (R1-2100142) observed that PIR gain of their coordination scheme using the Type B-like resource is shown for unicast
o Source 11 (R1-2100828) observed that their coordination scheme using the Type B-like resource is beneficial compared to Rel-16 Mode 2 RA for groupcast
§ Aperiodic traffic
o Source 13 (R1-2101910) observed that their coordination scheme using the Type B-like resource is beneficial compared to Rel-16 Mode 2 RA for groupcast with SL HARQ-ACK feedback Option 1
o Source 7 (R1-2100352) observed that their coordination scheme using the Type B-like resource is not beneficial compared to Rel-16 Mode 2 RA for unicast
o Combination of Type A and B
§ Periodic traffic
o Combination of Type A and B
§ Aperiodic traffic
o Source 7 (R1-2100352) observed that their coordination scheme using a combination of Type A-like and B-like resources is not beneficial compared to Rel-16 Mode 2 RA for unicast
· W/ signaling overhead, w/o latency
o Type A
§ Periodic traffic
o When UE-A sends to UE-B the set of resources preferred for UE-B’s transmission,
§ Aperiodic traffic
o When UE-A sends to UE-B the set of resources preferred for UE-B’s transmission,
o Type B
§ Periodic traffic
o Source 6 (R1-2101911) observed that their coordination scheme using the Type B-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast
o Source 6 (R1-2101911) observed that the gain of their coordination scheme using Type B-like resource becomes larger under the scenario where UL transmission can overlap with SL transmission/reception for unicast
o Source 11 (R1-2100828) observed that their coordination scheme using the Type B-like resource with enhanced mechanism of UE-A selection is beneficial for groupcast
§ Aperiodic traffic
o Source 6 (R1-2101911) observed that their coordination scheme using the Type B-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast
o Source 6 (R1-2101911) observed that their coordination scheme using the gain of Type B-like resource becomes larger under the scenario where UL transmission can overlap with SL transmission/reception for unicast
· W/o signaling overhead, w/o latency
o Type A
§ Periodic traffic
o When UE-A sends to UE-B the set of resources preferred for UE-B’s transmission,
§ Source 8 (R1-2101232) observed that their coordination scheme using the Type A-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast
§ Source 3 (R1-2100746) observed that their coordination scheme using the Type A-like resource is beneficial compared to Rel-16 Mode 2 RA for groupcast with SL HARQ-ACK feedback Option 1
§ Source 4 (R1-2101786) observed that their coordination scheme using the Type A-like resource is beneficial compared to Rel-16 Mode 2 RA for broadcast
§ Aperiodic traffic
o When UE-A sends to UE-B the set of resources used for UE-B’s transmission,
o When UE-A sends to UE-B the set of resources preferred for UE-B’s transmission,
o Type B
§ Periodic traffic
· Source 11 (R1-2100828) observed that their coordination scheme using the Type B-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast
· Source 11 (R1-2100828) observed that their coordination scheme using the Type B-like resource is beneficial compared to Rel-16 Mode 2 RA for groupcast
· Source 9 (R1-2101926) observed that their coordination scheme using the Type B-like resource is beneficial compared to Rel-16 Mode 2 RA for unicast
R1-2102166 Detailed observations from evaluation results Moderator (LG Electronics)
R1-2102165 Draft LS on Mode 2 enhancements in NR sidelink LG Electronics
Decision: The draft LS is endorsed, along with the attachment R1-2102166. Final LS is approved in R1-2102168.
Including remaining issues for sidelink evaluation methodology update for power saving, if any
R1-2100143 Remaining issues in sidelink evaluation methdology for power saving OPPO
R1-2100353 Remaining issues on sidelink evaluation methodology CATT, GOHIGH
R1-2100468 Other aspects on SL enhancements vivo
R1-2100519 Discussion on remaining aspects of sidelink evaluation methodology update for power saving LG Electronics
R1-2100689 Remaining evaluation assumptions and methodology for power saving Ericsson
R1-2100926 Discussion on remaining issues for sidelink evaluation methodology ZTE, Sanechips
R1-2100983 On SL multi-carrier operation and remaining issues for simulation methodology update InterDigital, Inc.
R1-2101099 Discussion on remaining issues of sidelink evaluation methodology Xiaomi
R1-2101233 On Sidelink Issues and RAN1 Impacts Samsung
R1-2101254 Physical layer impacts of sidelink DRX Huawei, HiSilicon
[104-e-NR-R17-SL-03] – Teng (CATT)
Email discussion on 8.11.2 (remaining issues for sidelink evaluation methodology update for power saving)
- 1st check point: Jan 28
- 2nd check point: Feb 3
R1-2101801 FL summary #1 on other issues in NR Sidelink enhancement Moderator (CATT)
Agreements:
·
For commercial use case, at least following layout options are supported:
o Option 3 of TR 36.843: Urban macro (500m ISD) (all UEs outdoor)
§ UE dropping as in Table A.2.1.1-1
· All UEs are outdoors UEs
o Option 1: Urban macro (500m ISD) + 1 RRH/Indoor Hotzone per cell for optional
§ UE dropping as in Table A.2.1.1-1
· Mix of outdoor and indoor UEs
o Option 5 of TR 36.843: Urban macro (1732m ISD) for optional
§ UE dropping as in Table A.2.1.1-1
· All UEs are outdoors UEs
· Mix of outdoor and indoor UEs
Agreements:
·
For public safety use case,
at least the following options are
supported for traffic model:
o Option 2: VoIP model specified in TR 36.843
o Option 4: FTP model 3 in TR 38.840 with packet size of 0.5Mbytes and mean inter-arrival time of 200ms
o Option 7: Periodic traffic model 3 specified in TR 37.885
o Option 9: VoIP model specified in TR36.843 with change of the value of outage definition into 0.01 and with packet delay budget of 75 ms
· Companies are encouraged to provide results for more than one traffic model including option 7
Agreements:
· For V2P evaluation, the mixture of at least V2P traffic and V2V traffic is supported.
o Each Tx V-UE performs either only V2V traffic or only V2P traffic.
o NOTE: Companies are encouraged to report the ratio between V-UEs performing V2V traffic and V-UEs performing V2P traffic.
Final summary in:
R1-2102130 FL summary #2 on other issues in NR Sidelink enhancement Moderator (CATT)
Please refer to RP-202846 for detailed scope of the WI
R1-2103256 On Resource Allocation Enhacements Samsung
Including consideration of the impact of sidelink DRX, if any
//From AI5
[104b-e-NR-R17-Sidelink-LS-01] - Yuzhou (ZTE)
Email discussion/approval to reply LS in R1-2100021 (April 15th – 20th), conditioned on the progress and joint management in the sub-agenda
R1-2104148 Moderator summary of Email discussion/approval to reply LS in R1-2100021 Moderator (ZTE)
Decision: As per email decision posted on April 20th, no converge for a reply. Companies are encouraged to investigate further of the issue and provide views to the next e-meeting.
R1-2102323 Sidelink resource allocation to reduce power consumption Huawei, HiSilicon
R1-2102361 Sidelink resource allocation for power saving Nokia, Nokia Shanghai Bell
R1-2102411 Power saving mechanism in NR sidelink OPPO
R1-2102467 Discussion on sidelink resource allocation for power saving Spreadtrum Communications
R1-2102539 Resource allocation for sidelink power saving vivo
R1-2102575 Considerations on partial sensing in NR V2X CAICT
R1-2102606 Discussion on resource allocation for power saving CATT, GOHIGH
R1-2102708 Discussion on sidelink power saving MediaTek Inc.
R1-2102719 Considerations on partial sensing and DRX in NR sidelink Fujitsu
R1-2102780 Power consumption reduction for sidelink resource allocation FUTUREWEI
R1-2102797 Discussion on resource allocation for power saving Zhejiang Lab
R1-2102811 NR Sidelink Resource Allocation for UE Power Saving Fraunhofer HHI, Fraunhofer IIS
R1-2102897 Discussion on resource allocation for power saving CMCC
R1-2102965 Discussion on sidelink resource allocation enhancement for power saving Xiaomi
R1-2103048 Sidelink power saving solutions Intel Corporation
R1-2103121 Discussion on Sidelink Resource Allocation for Power Saving Apple
R1-2103184 Power Savings for Sidelink Qualcomm Incorporated
R1-2103257 On Resource Allocation for Power Saving Samsung
R1-2103272 Discussion on Sidelink Resource Allocation for Power Saving Panasonic Corporation
R1-2103314 Discussion on sidelink resource allocation for power saving Sony
R1-2103331 Discussion on resource allocation for power saving ETRI
R1-2103378 Discussion on resource allocation for power saving LG Electronics
R1-2103416 On Resource Allocation for Power Saving in NR Sidelink Convida Wireless
R1-2103483 Discussion on resource allocation for power saving Sharp
R1-2103517 Discussion on resource allocation for power saving NEC
R1-2103537 Sidelink resource allocation for power saving InterDigital, Inc.
R1-2103548 Sidelink resource allocation for power saving Lenovo, Motorola Mobility
R1-2103592 Discussion on sidelink resource allocation for power saving NTT DOCOMO, INC.
R1-2103635 Discussion on resource allocation for power saving Hyundai Motors
R1-2103640 Discussion on partial sensing and SL DRX impact ASUSTeK
R1-2103663 Resource allocation for power saving with partial sensing in NR sidelink enhancement ITL
R1-2103704 Resource allocation procedures for power saving Ericsson
R1-2103710 Discussion on resource allocation for power saving ZTE, Sanechips
[104b-e-NR-R17-Sidelink-01] – Kevin (OPPO)
Email discussion on resource allocation for power saving
- 1st check point: 4/15
- 2nd check point: 4/19
- 3rd check point: 4/20
R1-2104090 FL summary for AI 8.11.1.1 – resource allocation for power saving (1st check point) Moderator (OPPO)
R1-2104091 FL summary for AI 8.11.1.1 – resource allocation for power saving (2nd check point) Moderator (OPPO)
· In periodic-based partial sensing,
o It is not necessary to further discuss whether or not to introduce a threshold to re-define T1 and T2.
R1-2104092 FL summary for AI 8.11.1.1 – resource allocation for power saving (3rd check point) Moderator (OPPO)
Agreements:
· In periodic-based partial sensing,
o For the set of Preserve values, down-select to one of the following in RAN1#105-e
§ Alt.1: Preserve corresponds to all values from the configured set sl-ResourceReservePeriodList
§ Alt.2: A set of Preserve values is (pre-)configured and includes up to the full set of values from the configured set sl-ResourceReservePeriodList
· FFS if support multiple sets of Preserve values based on one or more metrics
· FFS whether/how to restrict the set of values
o For the k value, down-selection to one of the following in RAN1#105-e (further refinement of each of the alternatives is possible)
· Alt 1: Option 1 as in RAN1#104-e
· Alt 2: A modified Option 5 as in RAN1#104-e, where the modification is such that it also includes option 1
o FFS how to (pre-)configure (e.g. including bitmap), whether a maximum number of k values is needed, and whether it can be up to UE implementation to select a k value based on the (pre-)configuration
· FFS details, e.g., sensing before the resource (re)selection trigger or the first slot of the set of Y candidate slots subject to processing time restriction, etc.
· Note: companies are encouraged to provide more evaluations
Agreement:
Final summary in R1-2104093.
R1-2102324 Inter-UE coordination in sidelink resource allocation Huawei, HiSilicon
R1-2102362 Inter-UE coordination in mode 2 sidelink resource allocation Nokia, Nokia Shanghai Bell
R1-2102412 Inter-UE coordination in mode 2 of NR sidelink OPPO
R1-2102468 Discussion on inter-UE coordination in sidelink resource allocation Spreadtrum Communications
R1-2102540 Discussion on mode-2 enhancements vivo
R1-2102576 Considerations on mode 2 enhancements CAICT
R1-2102607 Discussion on inter-UE coordination in mode 2 enhancement CATT, GOHIGH
R1-2102690 Discussion on Mode 2 enhancements MediaTek Inc.
R1-2102720 Considerations on inter-UE coordination for mode 2 enhancements Fujitsu
R1-2102781 Discussion on techniques for inter-UE coordination FUTUREWEI
R1-2102798 Inter-UE coordination for mode 2 enhancements Zhejiang Lab
R1-2102812 Resource Allocation Enhancements for Mode 2 Fraunhofer HHI, Fraunhofer IIS
R1-2102826 Inter-UE coordination for enhanced resource allocation Mitsubishi Electric RCE
R1-2102898 Discussion on enhancements for mode-2 resource allocation CMCC
R1-2102921 Discussion on the inter-UE coordination ZTE
R1-2102966 Discussion on inter-UE coordination Xiaomi
R1-2103049 Inter-UE coordination solutions for sidelink resource allocation mode-2 Intel Corporation
R1-2103122 Discussion on Inter-UE Coordination Apple
R1-2103185 Reliability and Latency Enhancements for Mode 2 Qualcomm Incorporated
R1-2103258 On Inter-UE Coordination for Mode2 Enhancements Samsung
R1-2103271 Inter-UE coordination for mode 2 enhancement ITL
R1-2103315 Discussion on reliability and latency enhancements for mode 2 Sony
R1-2103332 Discussion on mode 2 enhancements ETRI
R1-2103379 Discussion on inter-UE coordination for Mode 2 enhancements LG Electronics
R1-2103417 On Inter-UE Coordination for Mode 2 Enhancements Convida Wireless
R1-2103484 Discussion on inter-UE coordination for Mode 2 enhancements Sharp
R1-2103518 Discussion on mode 2 enhancements NEC
R1-2103538 On Inter-UE coordination for Mode 2 enhancement InterDigital, Inc.
R1-2103549 Discussion on inter-UE coordination for Mode 2 enhancements Lenovo, Motorola Mobility
R1-2103593 Resource allocation for reliability and latency enhancements NTT DOCOMO, INC.
R1-2103605 Inter-UE coordination for Mode 2 enhancements Panasonic Corporation
R1-2103636 Discussion on mode 2 enhancements Hyundai Motors
R1-2103648 Discussion on V2X mode 2 enhancements ASUSTeK
R1-2103705 Mode 2 enhancements using Inter-UE coordination Ericsson
[104b-e-NR-R17-Sidelink-02] – Seungmin (LGE)
Email discussion on inter-UE coordination for mode 2 enhancements
- 1st check point: 4/15
- 2nd check point: 4/19
- 3rd check point: 4/20
R1-2104103 Feature lead summary for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
Agreements:
· Support the following schemes of inter-UE coordination in Mode 2:
o Inter-UE Coordination Scheme 1:
§ The coordination information sent from UE-A to UE-B is the set of resources preferred and/or non-preferred for UE-B’s transmission
· FFS details including a possibility of down-selection between the preferred resource set and the non-preferred resource set, whether or not to include any additional information other than indicating time/frequency of the resources within the set in the coordination information
§ FFS condition(s) in which Scheme 1 is used
o Inter-UE Coordination Scheme 2:
§ The coordination information sent from UE-A to UE-B is the presence of expected/potential and/or detected resource conflict on the resources indicated by UE-B’s SCI
· FFS details including a possibility of down-selection between the expected/potential conflict and the detected resource conflict
§ FFS condition(s) in which Scheme 2 is used
Agreements:
· Study further to determine the conditions for UEs to be UE-A(s)/UE-B(s) for inter-UE coordination:
o E.g., only UE(s) among the intended receiver(s) of UE-B can be a UE-A, any UE can be a UE-A, high-layer configured, etc.
§ Including the possibility of being subject to certain conditions and/or capability
Agreements:
· When UE-B receives the inter-UE coordination information from UE-A, consider at least one of the following options (with details FFS including possibly down-selecting/merging one or more of the options below, applicable scenario(s)/condition(s) for each option, UE behavior) for UE-B’s to take it into account in the resource (re)-selection for its own transmission
o For scheme 1:
§ Option 1-1: UE-B’s resource(s) to be used for its transmission resource (re)-selection is based on both UE-B’s sensing result (if available) and the received coordination information
§ Option 1-2: UE-B’s resource(s) to be used for its transmission resource (re)-selection is based only on the received coordination information
§ Option 1-3: UE-B’s resource(s) to be re-selected based on the received coordination information
§ Option 1-4: UE-B’s resource(s) to be used for its transmission resource (re)-selection is based on the received coordination information
o For scheme 2:
§ Option 2-1: UE-B can determine resource(s) to be re-selected based on the received coordination information
§ Option 2-2: UE-B can determine a necessity of retransmission based on the received coordination information
R1-2102413 Wake up signal for NR sidelink OPPO
R1-2102541 Other aspects on SL enhancements vivo
R1-2102608 Considerations on other aspects of NR mode2 enhancements CATT, GOHIGH
R1-2102967 Discssion on other design aspects for sidelink enhancement Xiaomi
R1-2103123 Network Assisted Resource Selection Apple
R1-2103259 On Sidelink Issues and RAN1 Impacts Samsung
R1-2103392 Physical layer impacts of sidelink DRX Huawei, HiSilicon
R1-2103539 On gNB-designated resources for inter-UE coordination InterDigital, Inc.
R1-2103706 Additional considerations for resource allocation procedures Ericsson
R1-2103711 Discussion on remaining issues for sidelink evaluation methodology ZTE, Sanechips
Please refer to RP-202846 for detailed scope of the WI
R1-2105203 Consolidation of agreements on sidelink evaluation methodology update for power saving LG Electronics
//From AI5
[105-e-NR-R17-Sidelink-LS-01] - Yuzhou Hu (ZTE)
Email discussion/approval for the reply LS to R1-2100021 from 5/21 to 5/26
R1-2106135 Moderator Summary #1 of email discussion or approval to reply LS in R1-2100021 Moderator (ZTE)
R1-2106366 Moderator Summary #2 of email discussion or approval to reply LS in R1-2100021 Moderator (ZTE)
R1-2106367 Moderator Summary #3 of email discussion or approval to reply LS in R1-2100021 Moderator (ZTE)
R1-2106368 Moderator Summary #4 of email discussion or approval to reply LS in R1-2100021 Moderator (ZTE)
Decision: As per email decision posted on May 27th, there is no conclusion on this thread. Chair strongly encouraged everyone to do more analysis and evaluations, so that RAN1 can conclude in the next e-meeting.
R1-2105333 On Resource Allocation Enhacements Samsung
Including consideration of the impact of sidelink DRX, if any
R1-2104176 Sidelink resource allocation for power saving Nokia, Nokia Shanghai Bell
R1-2104192 Power consumption reduction for sidelink resource allocation FUTUREWEI
R1-2104236 Sidelink resource allocation to reduce power consumption Huawei, HiSilicon
R1-2106067 Resource allocation for sidelink power saving vivo (rev of R1-2104385)
R1-2104440 Discussion on sidelink resource allocation for power saving Spreadtrum Communications
R1-2104489 Discussion on resource allocation for power saving CATT, GOHIGH
R1-2104560 NR Sidelink Resource Allocation for UE Power Saving Fraunhofer HHI, Fraunhofer IIS
R1-2104630 Discussion on resource allocation for power saving CMCC
R1-2104693 Power Savings for Sidelink Qualcomm Incorporated
R1-2104706 Discussion on resource allocation for power saving Zhejiang Lab
R1-2104724 Considerations on partial sensing in NR V2X CAICT
R1-2104755 Power saving mechanisms in NR sidelink OPPO
R1-2104869 Sidelink resource allocation for power saving Lenovo, Motorola Mobility
R1-2104926 Sidelink Power Saving Schemes Intel Corporation
R1-2105066 Considerations on partial sensing and DRX in NR Sidelink Fujitsu
R1-2105070 Discussion on Sidelink Resource Allocation for Power Saving Panasonic Corporation
R1-2105126 On Sidelink Resource Allocation for Power Saving Apple
R1-2105177 Discussion on sidelink resource allocation for power saving Sony
R1-2106098 Discussion on resource allocation for power saving LG Electronics (rev of R1-2105204)
R1-2105228 Discussion on resource allocation for power saving ETRI
R1-2105253 Discussion on resource allocation for power saving NEC
R1-2105334 On Resource Allocation for Power Saving Samsung
R1-2105380 Discussion on sidelink power saving MediaTek Inc.
R1-2105544 Discussion on sidelink resource allocation enhancement for power saving Xiaomi
R1-2105598 NR SL Resource Allocation for Power Saving Convida Wireless
R1-2106122 Discussion on resource allocation for power saving ZTE, Sanechips (rev of R1-2105614)
R1-2105615 Discussion on resource allocation for power saving Hyundai Motors
R1-2105645 Discussion on resource allocation for power saving Sharp
R1-2105651 Resource allocation for power saving with partial sensing in NR sidelink enhancement ITL
R1-2105674 Sidelink resource allocation for power saving InterDigital, Inc.
R1-2105718 Discussion on sidelink resource allocation for power saving NTT DOCOMO, INC.
R1-2105845 Discussion on partial sensing and SL DRX impact ASUSTeK
R1-2105866 Further discussion on power saving for sidelink ROBERT BOSCH GmbH
R1-2105893 Resource allocation procedures for power saving Ericsson
[105-e-NR-R17-Sidelink-01] – Kevin (OPPO)
Email discussion regarding resource allocation for power saving
R1-2106030 FL summary for AI 8.11.1.1 – resource allocation for power saving (1st check point) Moderator (OPPO)
R1-2106031 FL summary for AI 8.11.1.1 – resource allocation for power saving (2nd check point) Moderator (OPPO)
From GTW session:
Agreement:
· For the set of Preserve values in periodic-based partial sensing,
o If no (pre-)configuration (i.e., by default), Preserve corresponds to all values from the (pre-)configured set sl-ResourceReservePeriodList.
o Otherwise, a single set of Preserve values can be (pre-)configured, where the set of Preserve values are restricted to a subset of the (pre-)configured set sl-ResourceReservePeriodList
§ This is per mode 2 Tx resource pool (pre-)configuration
§ A UE by implementation may also monitor other sl-ResourceReservePeriodList values not part of the restricted subset
· In particular, the UE may additionally monitor occasions corresponding to P_RSVP_Tx
o FFS whether the monitoring can be mandatory
R1-2106032 FL summary for AI 8.11.1.1 – resource allocation for power saving (final check point) Moderator (OPPO)
From GTW session:
Agreement:
· In periodic-based partial sensing for resource (re)selection, the UE at least monitors in periodic sensing occasion(s) for a given reservation periodicity before the first slot of the selected Y candidate slots subject to processing time restriction for the identification of candidate resources.
o The processing time restriction includes Tproc,0SL and Tproc,1SL.
o Aspects relating to sensing during SL DRX are to be discussed separately
· Relationship to re-evaluation and pre-emption operation for periodic-based partial sensing to be discussed separately
o FFS details including whether monitoring of periodic sensing occasions between triggering slot n and the first slot of the selected Y candidate slots subject to processing time restriction is performed as part of resource (re)selection or re-evaluation and pre-emption checking
Agreement:
· For the k value in periodic-based partial sensing for resource (re)selection,
o By default, the UE monitors the most recent sensing occasion for a given reservation periodicity before the resource (re)selection trigger slot n or the first slot of the set of Y candidate slots subject to processing time restriction.
o If (pre-)configured, UE additionally monitors periodic sensing occasions that correspond to a set of values which can be (pre-)configured with at least one value
§ (Working assumption) Possible values correspond to the most recent sensing occasion for a given reservation periodicity before the resource (re)selection trigger slot n or the first slot of the set of Y candidate slots, and the last periodic sensing occasion prior to the most recent one for the given reservation periodicity are included.
§ FFS: whether/which other values and details of the (pre-)configuration (e.g. max number of values or sensing occasions)
§ FFS: whether a value denotes a specific occasion to monitor or the earliest occasion to start the monitoring.
o FFS relationship between periodic-based partial sensing occasions and SL-DRX
o Note:
§ This is for the case when the resource (re)selection triggering slot n is expected by UE
Agreement:
· For random resource selection,
o Reuse the maximum distance separation of 32 logical slots for a HARQ retransmission resource reserved by a prior SCI for the same TB, which was defined in R16 for full sensing operation.
o SL HARQ feedback enabled transmission is supported (FFS applicable conditions if any)
§ The minimum HARQ feedback time gap (Z) shall be respected between any two selected resources of a TB where a HARQ feedback for the first of these resources is expected.
· FFS the impact of resource collision when random resource selection is performed by a UE which does not perform sensing / re-evaluation and pre-emption checking in a resource pool with mixed RA schemes (e.g. for low priority or any priority transmissions).
o Including study potential solution(s) if the impact is not negligible (e.g. threshold based, raising priority, minimum time gap, pattern based, a priori SCI reserving initial transmissions, resource pool partitioning, and etc.).
Agreement:
In contiguous partial sensing for resource (re)selection, TA and TB values can be zero, positive or negative
· TA and TB values or range depend on different operating scenarios or conditions (e.g., periodic/aperiodic traffic, predictability of triggering slot n, remaining PDB, re-evaluation/pre-emption checking, HARQ feedback, CBR/CR parameter, power saving, etc)
o FFS details
· FFS: details of how periodic-based partial sensing and contiguous partial sensing are used for re-evaluation and pre-emption checking. Including how to reduce UE’s power consumption (caused by additional sensing operation of re-evaluation/pre-emption) after its resource selection, with the considerations of different operating scenarios or conditions (e.g., pre-emption enabled/disabled, HARQ-ACK enabled/disabled, etc).
Final summary in:
R1-2106033 FL summary for AI 8.11.1.1 – resource allocation for power saving (final EOM) Moderator (OPPO)
R1-2104177 Inter-UE coordination in mode 2 sidelink resource allocation Nokia, Nokia Shanghai Bell
R1-2104193 Discussion on techniques for inter-UE coordination FUTUREWEI
R1-2104237 Inter-UE coordination in sidelink resource allocation Huawei, HiSilicon
R1-2106200 Discussion on mode-2 enhancements vivo (rev of R1-2104386)
R1-2104441 Discussion on inter-UE coordination in sidelink resource allocation Spreadtrum Communications
R1-2104457 Inter-UE Coordination for Mode 2 Enhancements Kyocera Corporation
R1-2104490 Discussion on inter-UE coordination in mode 2 enhancement CATT, GOHIGH
R1-2104561 Resource Allocation Enhancements for Mode 2 Fraunhofer HHI, Fraunhofer IIS
R1-2104631 Discussion on reliability and latency enhancements for mode-2 resource allocation CMCC
R1-2105982 Reliability and Latency Enhancements for Mode 2 Qualcomm Incorporated (rev of R1-2104694)
R1-2104707 Inter-UE coordination schemes in mode 2 Zhejiang Lab
R1-2104725 Considerations on mode 2 enhancements CAICT
R1-2104756 Inter-UE coordination in mode 2 of NR sidelink OPPO
R1-2104870 Discussion on inter-UE coordination for Mode 2 enhancements Lenovo, Motorola Mobility
R1-2104927 Inter-UE Coordination Schemes for Sidelink Communication Intel Corporation
R1-2105067 Considerations on inter-UE coordination for mode 2 enhancements Fujitsu
R1-2105127 On Inter-UE Coordination Apple
R1-2105178 Discussion on inter-UE coordination for Mode 2 enhancements Sony
R1-2105200 Discussion on the inter-UE coordination ZTE
R1-2105205 Discussion on inter-UE coordination for Mode 2 enhancements LG Electronics
R1-2105229 Discussion on inter-UE coordination for Mode 2 enhancements ETRI
R1-2105254 Discussion on mode 2 enhancements NEC
R1-2105270 Inter-UE coordination for enhanced resource allocation Mitsubishi Electric RCE
R1-2105335 On Inter-UE Coordination for Mode2 Enhancements Samsung
R1-2105393 Discussion on Mode 2 enhancements MediaTek Inc.
R1-2105545 Discussion on inter-UE coordination Xiaomi
R1-2105599 NR SL Inter-UE Coordination for Mode 2 Enhancements Convida Wireless
R1-2105616 Discussion on inter-UE coordination for Mode 2 enhancements Hyundai Motors
R1-2105646 Discussion on inter-UE coordination for Mode 2 enhancements Sharp
R1-2105650 Inter-UE coordination for Mode 2 enhancements Panasonic Corporation
R1-2105659 Inter-UE coordination for mode 2 enhancements ITL
R1-2105675 On inter-UE coordination for Mode 2 enhancement InterDigital, Inc.
R1-2105719 Resource allocation for reliability and latency enhancements NTT DOCOMO, INC.
R1-2105848 Discussion on V2X mode 2 enhancements ASUSTeK
R1-2105881 Discussion on inter-UE coordination for sidelink mode-2 ROBERT BOSCH GmbH
R1-2105894 Feasibility and benefits of mode 2 enhancements for inter-UE coordination Ericsson
[105-e-NR-R17-Sidelink-02] – Seungmin (LGE)
Email discussion regarding inter-UE coordination for Mode 2 enhancements
R1-2106062 Feature lead summary for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
R1-2106188 Feature lead summary#2 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
R1-2106284 Feature lead summary#3 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
R1-2106338 Feature lead summary#4 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
Void (not be handled during this e-meeting). No contributions please.
Please refer to RP-202846 for detailed scope of the WI
Including consideration of the impact of sidelink DRX, if any
R1-2106477 Sidelink resource allocation to reduce power consumption Huawei, HiSilicon
R1-2106531 Resource allocation for power saving Nokia, Nokia Shanghai Bell
R1-2106620 Resource allocation for sidelink power saving vivo
R1-2106714 Discussion on sidelink resource allocation for power saving Spreadtrum Communications
R1-2106724 Discussion on resource allocation for power saving Zhejiang Lab
R1-2106818 Discussion on sidelink resource allocation for power saving Sony
R1-2106909 On Resource Allocation for Power Saving Samsung
R1-2108238 Discussion on sidelink resource allocation enhancements for power saving CATT, GOHIGH (rev of R1-2106942)
R1-2107021 Discussion on Sidelink Resource Allocation for Power Saving Panasonic Corporation
R1-2107022 NR Sidelink Resource Allocation for UE Power Saving Fraunhofer HHI, Fraunhofer IIS
R1-2107037 Considerations on partial sensing and DRX in NR Sidelink Fujitsu
R1-2107091 Power consumption reduction for sidelink resource allocation FUTUREWEI
R1-2107151 Discussion on resource allocation for power saving NEC
R1-2107163 Sidelink resource allocation for power saving Lenovo, Motorola Mobility
R1-2107171 Considerations on partial sensing mechanism of NR V2X CAICT
R1-2107195 Discussion on resource allocation for power saving Hyundai Motors
R1-2107223 Discussion on power saving in NR sidelink communication OPPO
R1-2107367 Power Savings for Sidelink Qualcomm Incorporated
R1-2107422 Discussion on resource allocation for power saving CMCC
R1-2107481 Discussion on resource allocation for power saving ETRI
R1-2107498 Discussion on sidelink power saving MediaTek Inc.
R1-2107528 Discussion on resource allocation for power saving LG Electronics
R1-2107609 Sidelink Resource Allocation Schemes for UE Power Saving Intel Corporation
R1-2107760 Sidelink Resource Allocation for Power Saving Apple
R1-2107804 Discussion on resource allocation for power saving Sharp
R1-2107879 Discussion on sidelink resource allocation for power saving NTT DOCOMO, INC.
R1-2107899 Discussion on sidelink resource allocation enhancement for power saving Xiaomi
R1-2108023 Resource Allocation for Power Saving in NR SL Convida Wireless
R1-2108035 Sidelink resource allocation for power saving InterDigital, Inc.
R1-2108085 Discussion on resource allocation for power saving ZTE, Sanechips
R1-2108096 Discussion on partial sensing and SL DRX impact ASUSTeK
R1-2108121 Resource allocation for power saving in NR sidelink enhancement ITL
R1-2108136 Resource allocation procedures for power saving Ericsson
[106-e-NR-R17-Sidelink-01] – Kevin (OPPO)
Email discussion on resource allocation for power saving
- 1st check point: August 19
- 2nd check point: August 25
- 3rd check point: August 27
R1-2108262 FL summary for AI 8.11.1.1 – resource allocation for power saving (before 1st check point) Moderator (OPPO)
Agreement
In periodic-based partial sensing, UE monitoring of periodic sensing occasions between triggering slot n and the first slot of the selected Y candidate slots subject to processing time restriction is performed as part of resource (re)selection.
Agreement
Conditions in which contiguous partial sensing is performed by UE, when at least all of the followings are met:
· L1 [is expected to be or] is triggered by higher layer to report resources for resource (re-)selection in a mode 2 Tx pool
o FFS: When the trigger will be received by L1
· The resource pool is (pre-)configured to enable partial sensing
· Partial sensing is configured by higher layer in the UE
Agreement
For a resource pool (pre-)configured with at least partial sensing and UE is configured by its higher layer for partial sensing,
· Periodic-based partial sensing and contiguous partial sensing schemes are supported for resource re-evaluation and pre-emption checking
o FFS details of partial sensing for re-evaluation and pre-emption checking, including any restrictions / conditions on performing PBPS and CPS, subset of resources, timing, candidate resource set (SA) and etc
·
Same as in Rel-16, the
higher layer indicates a set of resources 
and/or a set of resources 
for re-evaluation and/or pre-emption checking, respectively
o Pre-emption checking is enabled according to the Release-16 interpretation of sl-PreemptionEnable.
§ FFS: If additional enhancements are needed for enabling/disabling
· The triggering of re-evaluation and pre-emption checking is as in R16.
Agreement
When UE performs only contiguous partial sensing (CPS) in a mode 2 Tx pool with periodic reservation for another TB (sl-MultiReserveResource) disabled, and a resource (re)selection is triggered in slot n,
Agreement
For random resource selection in a resource pool (pre-)configured with full/partial sensing and random resource selection, down-select to one of the followings in RAN1#106bis-e
Agreement
When UE performs periodic-based and contiguous partial sensing schemes in a mode 2 Tx pool with periodic reservation for another TB (sl-MultiReserveResource) enabled,
When UE performs periodic-based and contiguous partial sensing schemes in a mode 2 Tx pool with periodic reservation for another TB (sl-MultiReserveResource) enabled,
› FFS details of TA and TB based on the agreement(s) from previous RAN1 meetings
FFS: The condition under which UE performs periodic-based and contiguous partial sensing schemes in a mode 2 Tx pool with periodic reservation for another TB (sl-MultiReserveResource) enabled
R1-2108263 FL summary for AI 8.11.1.1 – resource allocation for power saving (before 2nd check point) Moderator (OPPO)
R1-2108264 FL summary for AI 8.11.1.1 – resource allocation for power saving (before 3rd check point) Moderator (OPPO)
R1-2108265 FL summary for AI 8.11.1.1 – resource allocation for power saving (EOM) Moderator (OPPO)
[106-e-NR-R17-Sidelink-02] – Kevin (OPPO)
Reply LS to R1-2106413 (LS on time gap information in SCI, RAN2) by August 20th.
R1-2108266 Moderator summary for [106-e-NR-R17-Sidelink-02] Reply LS to R1-2106413 Moderator (OPPO)
Decision: As per email decision posted on Aug 26th,
Agreement
Regarding RAN2’s question, in RAN1’s opinion it is feasible, other than in the following exceptional cases:
R1-2108621 Draft reply LS on time gap information in SCI Moderator (OPPO)
Decision: As per email decision posted on Aug 26th, the draft LS is endorsed. Final version is approved in R1-2108622.
[106-e-NR-R17-Sidelink-03] – Yuzhou (ZTE)
Reply LS to R1-2100021 (LS to RAN1 on SL DRX design, RAN2, from RAN1#104-e) by August 25
R1-2108653 Summary of [106-e-NR-R17-Sidelink-03] email discussion to reply LS in R1-2100021 Moderator (ZTE)
Decision: As per GTW decision on Aug 26th,
Agreement
A UE can perform SL reception of PSCCH and RSRP measurement for sensing during its SL DRX inactive time.
Decision: As per email decision posted on Aug 26th,
Agreement
The proposed reply LS to RAN2 as in section 2.2 of x8653 is endorsed. Final approved version is:
R1-2108580 Reply LS on SL DRX design RAN1, ZTE
R1-2106478 Inter-UE coordination in sidelink resource allocation Huawei, HiSilicon
R1-2106532 Inter-UE coordination for Mode 2 enhancements Nokia, Nokia Shanghai Bell
R1-2106570 Inter-UE coordination for enhanced resource allocation Mitsubishi Electric RCE
R1-2108210 Discussion on mode-2 enhancements vivo (rev of R1-2106621)
R1-2106715 Discussion on inter-UE coordination in sidelink resource allocation Spreadtrum Communications
R1-2106725 Discussion on inter-UE coordination for mode 2 enhancements Zhejiang Lab
R1-2106819 Discussion on inter-UE coordination for Mode 2 enhancements Sony
R1-2106910 On Inter-UE Coordination for Mode2 Enhancements Samsung
R1-2106943 Discussion on inter-UE coordination in sidelink mode 2 CATT, GOHIGH
R1-2107023 Resource Allocation Enhancements for Mode 2 Fraunhofer HHI, Fraunhofer IIS
R1-2107038 Considerations on inter-UE coordination for mode 2 enhancements Fujitsu
R1-2107092 Discussion on techniques for inter-UE coordination FUTUREWEI
R1-2107152 Discussion on mode 2 enhancements NEC
R1-2107164 Discussion on inter-UE coordination for Mode 2 enhancements Lenovo, Motorola Mobility
R1-2107172 Considerations on mode 2 enhancements CAICT
R1-2107196 Discussion on inter-UE coordination for Mode 2 enhancements Hyundai Motors
R1-2107224 Inter-UE coordination in mode 2 of NR sidelink OPPO
R1-2107303 Inter-UE coordination for Mode 2 enhancements Panasonic Corporation
R1-2108627 Reliability and Latency Enhancements for Mode 2 Qualcomm Incorporated (rev of R1-2108340, rev of R1-2108272, rev of R1-2107368)
R1-2107423 Discussion on inter-UE coordination for mode 2 enhancement CMCC
R1-2107482 Discussion on inter-UE coordination for Mode 2 enhancements ETRI
R1-2107522 Discussion on Mode 2 enhancements MediaTek Inc.
R1-2107529 Discussion on inter-UE coordination for Mode 2 enhancements LG Electronics
R1-2107610 Design of Inter-UE Coordination Solutions for Sidelink Communication Intel Corporation
R1-2107621 Inter-UE Coordination for Mode 2 Enhancements Kyocera
R1-2107761 Discussion on Inter-UE Coordination Apple
R1-2107782 Discussion on inter-UE coordination ZTE
R1-2107805 Discussion on inter-UE coordination for mode 2 enhancements Sharp
R1-2107880 Resource allocation for reliability and latency enhancements NTT DOCOMO, INC.
R1-2107900 Discussion on inter-UE coordination Xiaomi
R1-2107994 Inter-UE coordination for mode 2 enhancements ITL
R1-2108024 Inter-UE Coordination for NR SL Mode 2 Enhancements Convida Wireless
R1-2108036 On inter-UE coordination for Mode 2 enhancement InterDigital, Inc.
R1-2108097 Discussion on V2X mode 2 enhancements ASUSTeK
R1-2108115 Feasibility and benefits for NR Sidelink mode 2 enhancements CEWiT
R1-2108137 Feasibility and benefits of mode 2 enhancements for inter-UE coordination Ericsson
[106-e-NR-R17-Sidelink-04] – Seungmin (LG Electronics)
Email discussion on inter-UE coordination for mode 2 enhancements
- 1st check point: August 19
- 2nd check point: August 25
- 3rd check point: August 27
R1-2108569 Feature lead summary for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
Agreement
For scheme 1, the following inter-UE coordination information signalling from UE-A is supported. FFS details including condition(s)/scenario(s) under which each information is enabled to be sent by UE-A and used by UE-B.
Agreement
For scheme 2, the following inter-UE coordination information signalling from UE-A is supported. FFS details including condition(s)/scenario(s) under which each information is enabled to be sent by UE-A and used by UE-B
Decision: As per email decision posted on Aug 23rd,
Agreement
Agreement
In scheme 2, at least the following is supported for UE(s) to be UE-A(s)/UE-B(s) in the inter-UE coordination transmission triggered by a detection of expected/potential resource conflict(s) in Mode 2:
Agreement
In scheme 2, the following UE-B’s behavior in its resource (re)selection is supported when it receives inter-UE coordination information from UE-A:
Agreement
In scheme 1, at least following UE-B’s behavior in its resource (re-)selection is supported when it receives inter-UE coordination information from UE-A:
· For preferred resource set, the following two options are supported:
o Option A): UE-B’s resource(s) to be used for its transmission resource (re-)selection is based on both UE-B’s sensing result (if available) and the received coordination information
§ UE-B uses in its resource (re-)selection, resource(s) belonging to the preferred resource set in combination with its own sensing result
· UE-B uses in its resource (re-)selection, resource(s) not belonging to the preferred resource set when condition(s) are met
o FFS: Details of condition(s)
· This option is supported when UE-B performs sensing/resource exclusion
· FFS: Other details (if any)
o Option B): UE-B’s resource(s) to be used for its transmission resource (re-)selection is based only on the received coordination information
§ UE-B uses in its resource (re-)selection, resource(s) belonging to the preferred resource set
· This option is supported at least when UE-B does not support sensing/resource exclusion
o FFS: Whether the support is conditional or UE capability
· FFS: Other details (if any)
o FFS: Other option(s), and other details (if any)
· For non-preferred resource set,
o UE-B’s resource(s) to be used for its transmission resource (re-)selection is based on both UE-B’s sensing result (if available) and the received coordination information
§ UE-B excludes in its resource (re-)selection, resource(s) overlapping with the non-preferred resource set
· FFS: Details including
o Whether/how UE-B can use in its resource (re-)selection, resource(s) overlapping with the non-preferred resource set, definition of the overlap, and other details (if any)
o When UE-B excludes in its resource (re-)selection, resource(s) overlapping with the non-preferred resource set
§ FFS: UE-B reselects in its resource (re-)selection, resource(s) to be used for its transmission when the resource(s) are fully/partially overlapping with the non-preferred resource set
o FFS: Other option(s), and other details (if any)
Agreement
In scheme 2, at least the following is supported to determine inter-UE coordination information:
· Among resource(s) indicated by UE-B’s SCI, UE-A considers that expected/potential resource conflict occurs on the resource(s) satisfying at least one of the following condition(s):
o Condition 2-A-1:
§ Other UE’s reserved resource(s) identified by UE-A are fully/partially overlapping with resource(s) indicated by UE-B’s SCI in time-and-frequency
§ FFS: Other details (if any)
§ FFS: Whether/how to specify additional criteria and other details (if any) including signaling details of conflict indication
o (Working Assumption) Condition 2-A-2:
§ Resource(s) (e.g., slot(s)) where UE-A, when it is intended receiver of UE-B, does not expect to perform SL reception from UE-B due to half duplex operation
· FFS: Other details (if any)
o FFS: Other condition(s)
· FFS: Other details (if any)
Agreement
In scheme 1, at least the following is supported to determine inter-UE coordination information of preferred resource set:
· UE-A considers any resource(s) satisfying all the following condition(s) as set of resource(s) preferred for UE-B’s transmission
o Condition 1-A-1:
§ Resource(s) excluding those overlapping with reserved resource(s) of other UE identified by UE-A whose RSRP measurement is larger than a RSRP threshold
· FFS: Other details (if any)
o FFS: Condition 1-A-2:
§ Resource(s) excluding slot(s) where UE-A, when it is intended receiver of UE-B, does not expect to perform SL reception from UE-B
· FFS: Other details (if any)
o FFS: Condition 1-A-3:
§ Resource(s) satisfying UE-B’s traffic requirement (if available)
· FFS: Other details (if any)
o FFS: Other condition(s)
· FFS: Other details (if any)
Agreement
In scheme 1, at least the following is supported to determine inter-UE coordination information of non-preferred resource set:
· UE-A considers any resource(s) satisfying at least one of the following condition(s) as set of resource(s) non-preferred for UE-B’s transmission
o Condition 1-B-1:
§ Reserved resource(s) of other UE identified by UE-A from other UEs’ SCI (including priority field) and RSRP measurement
· FFS: Other details (if any)
o FFS: Condition 1-B-2:
§ Resource(s) (e.g., slot(s)) where UE-A, when it is intended receiver of UE-B, does not expect to perform SL reception from UE-B
· FFS: Other details (if any)
o FFS: Other condition(s)
· FFS: Other details (if any)
R1-2106622 Other aspects on SL enhancements vivo
R1-2106911 Discussion on Sidelink Enhancement Samsung
R1-2106944 Discussion on SL DRX configuration CATT, GOHIGH
R1-2107225 Wake up signal for NR sidelink OPPO
R1-2107762 Network Assisted Resource Selection Apple
R1-2107901 Discussion on other design aspects for sidelink enhancement Xiaomi
R1-2108037 On gNB-designated resources for inter-UE coordination InterDigital, Inc.
R1-2108086 BWP configuration for power saving ZTE, Sanechips
R1-2108138 Additional enhancements to resource allocation procedures Ericsson
R1-2108184 Physical layer impacts of sidelink DRX Huawei, HiSilicon
[106-e-NR-R17-Sidelink-05] – Rui (CATT)
Reply LS to R1-2106430 (LS on synchronous operation between Uu and SL in TDD band n79, RAN4) by August 20th.
R1-2108572 Summary for email discussion [106-e-NR-R17-Sidelink-05] Moderator (CATT)
Decision: As per email decision posted on Aug 26th, the email discussion is closed without any agreement or conclusion.
Please refer to RP-202846 for detailed scope of the WI.
Incoming LS(s) related to this work/study item under agenda item 5: R1-2108710.
[106bis-e-R17-RRC-Sidelink] – Seungmin (LGE)
Email discussion on Rel-17 RRC parameters for sidelink enhancement
- 1st check point: October 14
- Final check point: October 19
R1-2110649 [106bis-e-R17-RRC-Sidelink] Summary of email discussion on Rel-17 RRC parameters for sidelink enhancement Moderator (LG Electronics)
Document is noted. For consolidation under 8 in [106bis-e-R17-RRC].
R1-2110676 Summary of RAN1 agreements for Rel-17 NR sidelink enhancement WI rapporteur (LG Electronics)
[106bis-e-NR-R17-Sidelink-03] – Moonil (InterDigital)
Discuss incoming LS on resource selection for a possible reply LS by October 18
R1-2108710 LS to RAN1 on RAN2 Agreements Related to Resource Selection RAN2, InterDigital
R1-2110511 Moderator summary for [106bis-e-NR-R17-Sidelink-03] Reply LS to R1-2108710 Moderator (InterDigital)
Decision: As per email decision posted on Oct 20th,
Working Assumption
When PHY layer is indicated with an active time of RX UE from MAC layer for candidate resource selection, a restriction is applied in PHY layer so that at least a subset of candidate resources reported to MAC layer is located within the indicated active time of the RX UE. The following options will be further discussed in RAN1 to restrict resources for candidate resource selection taking into account the indicated active time from MAC layer:
· Option 1: PHY layer selects and reports candidate resources only within the indicated active time of the RX UE
· Option 2: PHY layer selects and reports candidate resources in which at least a subset of the candidate resources is within the indicated active time of the RX UE
· Option 3: PHY layer selects and reports an additional candidate resource set of candidate resources within the indicated active time of the RX UE
Above WA to be captured in the reply LS to RAN4.
R1-2110662 Reply LS on SL resource selection with DRX RAN1, InterDigital
Decision: As per email decision posted on Oct 20th, the LS is approved.
Including consideration of the impact of sidelink DRX, if any.
R1-2108763 Sidelink resource allocation to reduce power consumption Huawei, HiSilicon
R1-2108800 Power consumption reduction for sidelink resource allocation FUTUREWEI
R1-2108818 Resource allocation for power saving Nokia, Nokia Shanghai Bell
R1-2108924 Discussion on sidelink resource allocation for power saving Spreadtrum Communications
R1-2108998 Resource allocation for sidelink power saving vivo
R1-2109036 Considerations on partial sensing and DRX in NR Sidelink Fujitsu
R1-2109059 Discussion on power saving in NR sidelink communication OPPO
R1-2109129 Discussion on resource allocation for power saving NEC
R1-2109191 Further discussion on sidelink resource allocation enhancements for power saving CATT, GOHIGH
R1-2109300 Discussion on resource allocation for power saving CMCC
R1-2109348 Considerations on partial sensing mechanism of NR V2X CAICT
R1-2109384 Discussion on sidelink resource allocation enhancement for power saving Xiaomi
R1-2109430 NR Sidelink Resource Allocation for UE Power Saving Fraunhofer HHI, Fraunhofer IIS
R1-2109512 On Resource Allocation for Power Saving Samsung
R1-2109541 Sidelink resource allocation for power saving Lenovo, Motorola Mobility
R1-2109564 Remaining issues on sidelink power saving MediaTek Inc.
R1-2109631 Sidelink Resource Allocation Schemes for UE Power Saving Intel Corporation
R1-2109699 Discussion on sidelink resource allocation for power saving NTT DOCOMO, INC.
R1-2109731 Discussion on Sidelink Resource Allocation for Power Saving Panasonic Corporation
R1-2109732 Discussion on resource allocation for power saving ZTE, Sanechips
R1-2109800 Discussion on sidelink resource allocation for power saving Sony
R1-2109818 Discussion on resource allocation for power saving ETRI
R1-2109860 Discussion on resource allocation for power saving LG Electronics
R1-2109883 Sidelink resource allocation for power saving InterDigital, Inc.
R1-2110005 Discussion on resource allocation for power saving Sharp
R1-2110053 On Sidelink Resource Allocation for Power Saving Apple
R1-2110116 Discussion on NR SL Resource Allocation for Power Saving Convida Wireless
R1-2110131 Discussion on partial sensing and SL DRX impact ASUSTeK
R1-2110208 Power Savings for Sidelink Qualcomm Incorporated
R1-2110305 Resource allocation for power saving in NR sidelink enhancement ITL
R1-2110307 Further discussion on power saving for sidelink resource allocation ROBERT BOSCH GmbH
R1-2110339 Resource allocation procedures for power saving Ericsson
[106bis-e-NR-R17-Sidelink-01] – Kevin (OPPO)
Email discussion on resource allocation for power saving
- 1st check point: October 14
- Final check point: October 19
R1-2110476 FL summary for AI 8.11.1.1 – resource allocation for power saving (before 1st GTW) Moderator (OPPO)
R1-2110477 FL summary for AI 8.11.1.1 – resource allocation for power saving (before 2nd GTW) Moderator (OPPO)
From Oct 14th GTW session
Agreement
In the agreement from RAN1#105-e, the working assumption is confirmed and the FFS bullet (in RED) is closed without any agreement.
|
Agreement from RAN1#105-e: § For the k value in periodic-based partial sensing for resource (re)selection, o By default, the UE monitors the most recent sensing occasion for a given reservation periodicity before the resource (re)selection trigger slot n or the first slot of the set of Y candidate slots subject to processing time restriction. o If (pre-)configured, UE additionally monitors periodic sensing occasions that correspond to a set of values which can be (pre-)configured with at least one value § (Working assumption) Possible values correspond to the most recent sensing occasion for a given reservation periodicity before the resource (re)selection trigger slot n or the first slot of the set of Y candidate slots, and the last periodic sensing occasion prior to the most recent one for the given reservation periodicity are included. § FFS: whether/which other values and details of the (pre-)configuration (e.g. max number of values or sensing occasions) § FFS: whether a value denotes a specific occasion to monitor or the earliest occasion to start the monitoring. o FFS relationship between periodic-based partial sensing occasions and SL-DRX o Note: § This is for the case when the resource (re)selection triggering slot n is expected by UE |
Agreement
When UE performs periodic-based and contiguous partial sensing schemes in a mode 2 Tx pool with periodic reservation for another TB (sl-MultiReserveResource) enabled,
) in slot n,
TA and TB for the CPS monitoring
window is defined according to one of the followings:
, and n+TB
is 
slots earlier
than , where is the first slot
of the selected Y candidate slots of PBPS, and 
, 
are in
units of physical time/slots.
R1-2110478 FL summary for AI 8.11.1.1 – resource allocation for power saving (before 3rd GTW) Moderator (OPPO)
R1-2110479 FL summary for AI 8.11.1.1 – resource allocation for power saving (before 4th GTW) Moderator (OPPO)
From Oct 18th GTW session
Agreement
For the periodic sensing occasion(s) (PSO(s)) that a UE needs to additionally monitored in PBPS, it shall be (pre-)configured jointly for all Preserve values.
· The UE is not required to monitor PSOs earlier than n–T0 if the UE is triggered to do resource (re)selection in slot n, where T0 is (pre-)configured
Decision: As per email decision posted on Oct 20th,
Working Assumption
In a resource pool (pre-)configured to enable partial sensing, when UE is configured with partial sensing by its higher layer, the resources for which the UE performs re-evaluation and/or pre-emption checking are for the initial transmission and retransmissions of every TB according to Rel-16 specification based on partial sensing results.
· Same as in Rel-16, for periodic transmission, re-evaluation check is not applied to the resources that have been signalled in current period or previous periods, except that it is up to UE implementation whether to apply re-evaluation check to the resources in non-initial reservation period that have been signalled neither in the immediate last nor in the current period.
· The resource in the main bullet is the set of resources (r0,r1,r2,…) and/or the set of resources (r0',r1',r2',…) for re-evaluation and/or pre-emption checking, respectively, which has been agreed in RAN1 #106-e.
Decision: As per email decision posted on Oct 21st,
Agreement
When UE performs at least contiguous partial sensing in a mode 2 Tx pool for a resource (re)selection procedure triggered by aperiodic transmission (Prsvp_TX=0) in slot n, TA and TB for CPS monitoring window and a candidate resource set (SA) is initialized according to potentially one of the following approaches (final decision in RAN1#107-e). Other approaches are not precluded and the details in each approach can still be updated.
· Approach 1: (SA is initialized based on at least slots with PBPS and/or CPS results and guarantee a minimum of M slots for CPS)
o The UE selects a set of Y’ candidate slots with corresponding PBPS and/or CPS results (if available) within the RSW.
§ FFS how to handle the case if the total number of Y’ candidate slots is less than a (pre-)configured threshold Y’min without dropping the aperiodic transmission
§ FFS whether the Y’ candidate slots for aperiodic transmission is the same as the Y candidate slots in PBPS for periodic transmission of another TB(s)
§ FFS whether/how to prioritize/select resources based on partial sensing results.
§ FFS: How to select Y’ in case of CPS only
o Candidate resource set (SA) is initialized to the set of all single-slot candidate resources in the selected Y’ candidate slots.
o For the CPS monitoring window [n+TA, n+TB]:
§ TA and TB are both selected such that UE has sensing results for a minimum of M consecutive logical slots before ty0, where ty0 is the first slot of the selected Y’ candidate slots.
· FFS: By default, M is 31 unless (pre-)configured with another value, or M is (pre-)configured based on transmission priority
· FFS the range of (pre-)configured M from a TBD lowest value up to 30
· FFS: how to handle the case when the minimum M slots for CPS cannot be guaranteed
o FFS: RSW in case of CPS only
· Approach 2: (SA is initialized based on all candidate single-slot resources and guarantee a minimum of M slots for CPS)
o Candidate resource set (SA) is initialized to the set of all candidate single-slot resources in [n+TB+Tproc,0+Tproc,1, n+T2], where TB is selected by the UE such that length of [n+TB+Tproc,0+Tproc,1, n+T2] ≥ T2min.
§ Tproc,0, Tproc,1 are in units of physical time/slots
§ FFS whether/how to prioritize/select resources based on partial sensing results (if PBPS is performed).
o For the CPS monitoring window [n+TA, n+TB]:
§ TA = X
· FFS value X for TA including X=1 and negative value
§ TB is selected such that UE has sensing results for a minimum of M consecutive logical slots before the start of (n+TB+Tproc,0+Tproc,1).
· FFS: By default, M is 31 unless (pre-)configured with another value, or M is (pre-)configured based on transmission priority
· FFS the range of (pre-) configured M from a TBD lowest value up to 30
· FFS: how to handle the case when the minimum M slots for CPS cannot be guaranteed
· Approach 3: (independent approach for different case)
o When UE additionally performs periodic-based partial sensing in the resource pool, the above Approach 1 applies.
o When UE does not perform periodic-based partial sensing in a resource pool that does not allow resource reservation for another TB, the above Approach 2 applies.
Final summary
R1-2110480 FL summary for AI 8.11.1.1 – resource allocation for power saving (EOM) Moderator (OPPO)
R1-2108764 Inter-UE coordination in sidelink resource allocation Huawei, HiSilicon
R1-2108801 Discussion on techniques for inter-UE coordination FUTUREWEI
R1-2108819 Inter-UE coordination for Mode 2 enhancements Nokia, Nokia Shanghai Bell
R1-2108925 Discussion on inter-UE coordination in sidelink resource allocation Spreadtrum Communications
R1-2108999 Discussion on mode-2 enhancements vivo
R1-2109037 Considerations on inter-UE coordination for mode 2 enhancements Fujitsu
R1-2109060 Inter-UE coordination in mode 2 of NR sidelink OPPO
R1-2109130 Discussion on mode 2 enhancements NEC
R1-2109142 Inter-UE coordination for enhanced resource allocation Mitsubishi Electric RCE
R1-2109192 Discussion on Inter-UE coordination for Mode 2 enhancements CATT, GOHIGH
R1-2109301 Discussion on inter-UE coordination for mode 2 enhancement CMCC
R1-2109341 Feasibility and benefits for NR Sidelink mode 2 enhancements CEWiT
R1-2109349 Considerations on mode 2 enhancements CAICT
R1-2109385 Discussion on inter-UE coordination Xiaomi
R1-2109431 Resource Allocation Enhancements for Mode 2 Fraunhofer HHI, Fraunhofer IIS
R1-2109449 Discussion on inter-UE coordination for mode 2 enhancements Zhejiang Lab
R1-2109450 Discussion on inter-UE coordination for Mode 2 enhancements Hyundai Motors
R1-2109513 On Inter-UE Coordination for Mode2 Enhancements Samsung
R1-2109542 Inter-UE coordination for Mode 2 enhancements Lenovo, Motorola Mobility
R1-2109586 Discussion on Mode 2 enhancements MediaTek Inc.
R1-2109632 Solutions for sidelink communication with inter-UE coordination feedback Intel Corporation
R1-2109700 Resource allocation for reliability and latency enhancements NTT DOCOMO, INC.
R1-2109758 Inter-UE coordination for Mode 2 enhancements Panasonic Corporation
R1-2109801 Discussion on inter-UE coordination for Mode 2 enhancements Sony
R1-2109819 Discussion on inter-UE coordination for Mode 2 enhancements ETRI
R1-2109852 Discussion on inter-UE coordination ZTE
R1-2109861 Discussion on inter-UE coordination for Mode 2 enhancements LG Electronics
R1-2109884 On inter-UE coordination for Mode 2 enhancement InterDigital, Inc.
R1-2110006 Discussion on inter-UE coordination for mode 2 enhancements Sharp
R1-2110054 On Inter-UE Coordination Apple
R1-2110117 Discussion on Inter-UE Coordination for NR SL Mode 2 Enhancement Convida Wireless
R1-2110132 Discussion on V2X mode 2 enhancements ASUSTeK
R1-2110209 Reliability and Latency Enhancements for Mode 2 Qualcomm Incorporated
R1-2110306 Support of inter-UE coordination scheme 1 and scheme 2 ROBERT BOSCH GmbH
R1-2110340 Details on mode 2 enhancements for inter-UE coordination Ericsson
[106bis-e-NR-R17-Sidelink-02] – Seungmin (LGE)
Email discussion on inter-UE coordination for mode 2 enhancements
- 1st check point: October 14
- Final check point: October 19
From Oct 12th GTW session
Agreement
For Scheme 2, PSFCH format 0 is used to convey the presence of expected/potential resource conflict on reserved resource(s) indicated by UE-B’s SCI
Agreement
For Condition 2-A-1 of Scheme 2, down-select one or more of following additional criteria to determine resource(s) where expected/potential resource conflict occurs
· Option 1: The resource(s) are fully/partially overlapping in time-and-frequency with other UE’s reserved resource(s) whose RSRP measurement is larger than a RSRP threshold according to the priorities included in the SCI:
o prio_TX and prio_RX are the priorities indicated in the SCI making the overlapping reservations
o Strive to reuse Rel-16 specification wherever possible
· Option 2: The resource(s) are fully/partially overlapping in time-and-frequency with other UE’s reserved resource(s) whose RSRP measurement is within a (pre)configured RSRP threshold compared to the RSRP measurement of UE-B’s reserved resource.
o FFS: Whether the threshold depends on priority
· Option 3: The resource(s) are fully/partially overlapping in time-and-frequency with other UE’s reserved resource(s) and the other UE is within a distance threshold of UE-B as determined by both UEs’ SCIs.
· Option 4: The resource(s) are fully/partially overlapping in time-and-frequency with other UE’s reserved resource(s) whose RSRP measurement is larger a (pre)configured RSRP threshold compared to the RSRP measurement of UE-B’s reserved resource.
o FFS: Whether the threshold depends on priority
· FFS: In case of collisions of resources for two UEs having TBs with UE A as destination UE, if needed
Draft proposal 9:
For determining PSFCH resource in Scheme 2, down-select one of followings:
· Option 1: PSFCH occasion is derived by a slot where UE-B’s SCI is transmitted
o CATT, Qualcomm, Apple, Samsung, Ericsson, OPPO (with revision … UE-B’s SCI is the SCI indicating conflicting resources), Xiaomi
· Option 2: PSFCH occasion is derived by a slot where expected/potential resource conflict occurs on PSSCH resource indicated by UE-B’s SCI
o Intel, NTT DOCOMO, LGE, vivo, Sharp, MediaTek, Fujitsu, NEC, Futurewei
From Oct 15th GTW session
Working Assumption
· For Condition 1-B-1 of Scheme 1, the following two options are supported
o Option 1: Reserved resource(s) of other UE(s) identified by UE-A whose RSRP measurement is larger than a (pre)configured RSRP threshold which is determined by at least priority value indicated by SCI of the UE(s)
o Option 2: Reserved resource(s) of other UE identified by UE-A whose RSRP measurement is smaller than a (pre)configured RSRP threshold which is determined by at least priority value indicated by SCI of the UE(s) when UE-A is a destination of a TB transmitted by the UE(s)
Working Assumption
· For Scheme 1 with non-preferred resource set, support following condition:
o Condition 1-B-2:
§ Resource(s) (e.g., slot(s)) where UE-A, when it is intended receiver of UE-B, does not expect to perform SL reception from UE-B due to half duplex operation
Agreement
· For Condition 1-A-1 of Scheme 1, the set of resources preferred for UE-B’s transmission is a form of candidate single-slot resource as specified in Rel-16 TS 38.214 Section 8.1.4
o When the inter-UE coordination information transmission is triggered by UE-B’s explicit request, the candidate single-slot resource(s) are determined in the same way according to Rel-16 TS 38.214 Section 8.1.4 with at least following parameters provided by signaling from UE-B. FFS whether or not to apply RSRP threshold increase in Step 7) of Rel-16 TS 38.214 Section 8.1.4.
§ Priority value to be used for PSCCH/PSSCH transmission
· It replaces prio_TX
§ Number of sub-channels to be used for PSSCH/PSCCH transmission in a slot
· It replaces L_subCH
§ Resource reservation interval
· It replaces P_rsvp_TX
§ FFS: Starting/ending time location of resource selection window
o FFS: In addition to Rel-16 procedure, use inter-UE coordination information from other UEs
§ If there is no consensus in RAN1#106bis-e, no further discussions for Rel-17
From Oct 18th GTW session
Conclusion
No consensus that UE-A uses inter-UE coordination information from other UEs when it determines the preferred resource set for Condition 1-A-1 of Scheme 1.
Working Assumption
· For Scheme 1 with preferred resource set, support following condition:
o Condition 1-A-2:
§ Resource(s) excluding slot(s) where UE-A, when it is intended receiver of UE-B, does not expect to perform SL reception from UE-B due to half duplex operation
§ This can be disabled by RRC (pre-)configuration
From Oct 19th GTW session
Agreement
For allocating PSFCH resources in Scheme 2, at least following can be (pre)configured separately from those for SL HARQ-ACK feedback.
· Set of PRBs for PSFCH transmission/reception (sl-PSFCH-RB-Set)
Agreement
For Scheme 2,
· Index of a PSFCH resource for inter-UE coordination information transmission is determined in the same way according to Rel-16 TS 38.213 Section 16.3 with at least following modification
o P_ID is L1-Source ID indicated by UE-B’s SCI
o M_ID is 0
· FFS: How to set m_CS
· FFS: How to set m_0
· FFS: Whether M_ID can be (pre)configured
Final summary in
R1-2110674 Feature lead summary for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
R1-2109000 Other aspects on SL enhancements vivo
R1-2109061 Wake up signal for NR sidelink OPPO
R1-2109193 Discussion on SL DRX configuration granularity CATT, GOHIGH
R1-2109386 Discussion on other design aspects for sidelink enhancement Xiaomi
R1-2109514 Discussion on Sidelink Enhancement Samsung
R1-2109734 BWP configuration for power saving ZTE, Sanechips
R1-2109754 Physical layer impacts of sidelink DRX Huawei, HiSilicon
R1-2109885 On gNB-designated resources for inter-UE coordination and sensing in SL DRX InterDigital, Inc.
R1-2110055 Network Assisted Resource Selection Apple
R1-2110341 Additional enhancements to resource allocation procedures Ericsson
[106bis-e-NR-R17-Sidelink-04] – Rui (CATT)
Discuss incoming LS (R1-2106430) on synchronous operation between Uu and SL in TDD band n79 for a possible reply LS by October 18
R1-2110593 Summary for email discussion [106bis-e-NR-R17-Sidelink-04] Moderator (CATT)
Decision: As per email decision posted on Oct 20th,
Agreement
Reply LS to RAN4 with the following content is endorsed:
R1-2110586 Reply LS on synchronous operation between Uu and SL in TDD band n79 RAN1, GOHIGH
Decision: As per email decision posted on Oct 20th, the LS is approved.
Please refer to RP-202846 for detailed scope of the WI. Incoming LS(s) related to this work/study item under agenda item 5: R1-2110760.
Rel-17 CRs related to SL_enh
R1-2112490 Introduction of NR Sidelink enhancements Nokia
Decision: Draft CR to 38.214 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
[107-e-R17-RRC-Sidelink] – Seungmin (LGE)
Email discussion on Rel-17 RRC parameters for sidelink enhancement
- Email discussion to start on November 15
R1-2112650 [107-e-R17-RRC-Sidelink] Summary of email discussion on Rel-17 RRC parameters for sidelink enhancement Moderator (LG Electronics)
Document is noted. For consolidation under 8 in [107-e-R17-RRC].
R1-2112167 Candidate resource selection for SL DRX ITL
Including consideration of the impact of sidelink DRX, if any.
R1-2110844 Sidelink resource allocation to reduce power consumption Huawei, HiSilicon
R1-2110861 Resource allocation for power saving Nokia, Nokia Shanghai Bell
R1-2110886 Power consumption reduction for sidelink resource allocation FUTUREWEI
R1-2111036 Remaining issues on resource allocation for sidelink power saving vivo
R1-2111111 Discussion on sidelink resource allocation for power saving Spreadtrum Communications
R1-2111121 Discussion on Sidelink Resource Allocation for Power Saving Panasonic Corporation
R1-2111150 Considerations on partial sensing and DRX in NR Sidelink Fujitsu
R1-2111228 Remaining issues on sidelink resource allocation enhancements for power saving CATT, GOHIGH
R1-2111300 Discussion on power saving in NR sidelink communication OPPO
R1-2111406 Discussion on sidelink resource allocation for power saving Sony
R1-2111514 Remaining Details of Sidelink Resource Allocation Schemes for UE Power Saving Intel Corporation
R1-2111546 Discussion on sidelink resource allocation enhancement for power saving Xiaomi
R1-2111625 Discussion on resource allocation for power saving CMCC
R1-2111637 Discussion on resource allocation for power saving ZTE, Sanechips
R1-2111649 NR Sidelink Resource Allocation for UE Power Saving Fraunhofer HHI, Fraunhofer IIS
R1-2111656 Considerations on partial sensing mechanism of NR V2X CAICT
R1-2111699 Discussion on resource allocation for power saving NEC
R1-2111758 On Resource Allocation for Power Saving Samsung
R1-2111815 Discussion on resource allocation for power saving LG Electronics
R1-2111824 Sidelink resource allocation for power saving InterDigital, Inc.
R1-2111894 Sidelink Resource Allocation for Power Saving Apple
R1-2111997 Discussion on resource allocation for power saving ETRI
R1-2112024 Discussion on resource allocation for power saving Sharp
R1-2112033 On NR Resource Allocation for Power Saving Convida Wireless
R1-2112042 Discussion on partial sensing and SL DRX impact ASUSTeK
R1-2112126 Discussion on sidelink resource allocation for power saving NTT DOCOMO, INC.
R1-2112164 Sidelink resource allocation for power saving Lenovo, Motorola Mobility
R1-2112237 Power Savings for Sidelink Qualcomm Incorporated
R1-2112305 Remaining details on sidelink power saving MediaTek Inc.
R1-2112336 Resource allocation for power saving in NR sidelink enhancement ITL
R1-2112351 Resource allocation procedures for power saving Ericsson
R1-2112394 Discussion on sidelink enhancements for power saving ROBERT BOSCH GmbH
[107-e-NR-R17-Sidelink-01] – Kevin (OPPO)
Email discussion on resource allocation for power saving
- 1st check point: November 15
- Final check point: November 19
R1-2112524 FL summary for AI 8.11.1.1 – resource allocation for power saving (before 1st GTW) Moderator (OPPO)
From Nov 11th GTW session
Agreement
When UE performs at least contiguous partial sensing in a mode 2 Tx pool for a resource (re)selection procedure triggered by aperiodic transmission (Prsvp_TX=0) in slot n, the general design framework in Approach 1 from RAN1#106bis-e in below is adopted. Note that, the details can still be updated.
· Approach 1: (SA is initialized based on at least slots with PBPS and/or CPS results and guarantee a minimum of M slots for CPS)
o The UE selects a set of Y’ candidate slots with corresponding PBPS and/or CPS results (if available) within the RSW.
§ FFS how to handle the case if the total number of Y’ candidate slots is less than a (pre-)configured threshold Y’min without dropping the aperiodic transmission
§ FFS whether the Y’ candidate slots for aperiodic transmission is the same as the Y candidate slots in PBPS for periodic transmission of another TB(s)
§ FFS whether/how to prioritize/select resources based on partial sensing results.
§ FFS: How to select Y’ in case of CPS only
o Candidate resource set (SA) is initialized to the set of all single-slot candidate resources in the selected Y’ candidate slots.
o For the CPS monitoring window [n+TA, n+TB]:
§ TA and TB are both selected such that UE has sensing results for a minimum of M consecutive logical slots before ty0, where ty0 is the first slot of the selected Y’ candidate slots.
· FFS: By default, M is 31 unless (pre-)configured with another value, or M is (pre-)configured based on transmission priority
·
FFS the range of
(pre-)configured M from a TBD lowest value up to 30
· FFS: how to handle the case when the minimum M slots for CPS cannot be guaranteed
o FFS: RSW in case of CPS only
Agreement
When SL DRX active time of Rx-UE is provided by the higher layer for candidate resource selection (including resource (re)selection and re-evaluation/pre-emption checking), the following working assumption is confirmed with option 2 as agreement (with modification in RED)
Working Assumption (RAN1#106bis-e)
When PHY layer is indicated with an active time of RX UE from MAC layer for candidate resource selection, a restriction is applied in PHY layer so that at least a subset of candidate resources reported to MAC layer is located within the indicated active time of the RX UE. The following options will be further discussed in RAN1 to restrict resources for candidate resource selection taking into account the indicated active time from MAC layer:
·
Option
1: PHY layer selects and reports candidate resources only within the indicated
active time of the RX UE
· Option 2: PHY layer selects and reports candidate resources in which at least a subset of the candidate resources is within the indicated active time of the RX UE
· FFS: Details on when the number of subsets of candidate resource is less than the threshold
· FFS: The subset of candidate resource outside of the active time should consider each inactive time period
· FFS: UE selection of resource selection window to overlap with indicated RX UE active time
· FFS: Whether it is up to UE implementation to report candidate resources only within the indicated active time of the RX UE
·
Option
3: PHY layer selects and reports an additional candidate resource set of
candidate resources within the indicated active time of the RX UE
R1-2112525 FL summary for AI 8.11.1.1 – resource allocation for power saving (before 2nd GTW) Moderator (OPPO)
R1-2112526 FL summary for AI 8.11.1.1 – resource allocation for power saving (before 3rd GTW) Moderator (OPPO)
From Nov 17th GTW session
Agreement
When UE performs at least contiguous partial sensing in a mode 2 Tx pool for a resource (re)selection procedure triggered by aperiodic transmission (Prsvp_TX=0) in slot n,
· The UE selects a set of Y candidate slots with corresponding PBPS and/or CPS results (if available) within the RSW.
o If the total number of Y’ candidate slots is less than a (pre-)configured threshold Y’min,
§ How UE includes other candidate slots is up to UE implementation
· Candidate resource set (SA) is initialized to the set of all single-slot candidate resources in the selected Y’ candidate slots.
· For the CPS monitoring window [n+TA, n+TB]:
o TA and TB are both selected such that UE has sensing results starting at M consecutive logical slots before ty0 and ending at Tproc,0 + Tproc,1 slots earlier than ty0.
§
FFS: By default, M is
31 unless (pre-)configured with another value,
or where M is (pre-)configured
based on transmission priority
§
FFS: The range of
(pre-)configured M from a TBD lowest value up to 30
§ When the minimum M slots for CPS cannot be guaranteed, support both
· Option A, the UE ensures the Y’min criterion is fulfilled
· Option B: UE performs random resource selection
· When the UE performs Option A or Option B is up to UE implementation
Decision: As per email decision posted on Nov 18th,
Conclusion
|
No additional triggering enhancement on top of existing Rel-16 mechanism in re-evaluation and pre-emption checking for partial sensing UEs in Rel-17, including enabling / disabling re-evaluation by (pre-)configuration. |
· This does not restrict the triggering of re-evaluation and pre-emption checking due to inter-UE coordination message in scheme 2 (if agreed).
R1-2112527 FL summary for AI 8.11.1.1 – resource allocation for power saving (before 4th GTW) Moderator (OPPO)
Decision: As per email decision posted on Nov 20th,
Agreement
When UE is triggered to perform re-evaluation and pre-emption checking for periodic transmission (Prsvp_TX≠0) in slot n,
·
During the qth
reservation period (q=0,1,2,…, Cresel-1), candidate resource set
(SA) is initialized to the remaining Y candidate slots starts from slot 
and ends at the last slot of the Y candidate slots, where
the slot indices of the remaining Y candidate slots are equal to [q
x Prsvp_Tx + 
], where is a slot index of Y candidate slots used in the initial
resource (re)selection.
o
is the first candidate slot after slot n+T3.
o FFS whether/how to handle the case when number of the remaining Y candidate slots is less than Ymin.
· Scheme 1:
o
UE performs PBPS for the
remaining Y candidate slots according to 
, where 
is a slot belong to the remaining Y
candidate slots, and k and Preserve are the same
as resource (re)selection.
o
UE performs CPS starts
from M logical slots earlier than to 
slots earlier than 
.
§ By default, M is 31 unless (pre-)configured with another value.
Agreement
When UE performs random resource selection, LTE principle is reused:
· The UE is not required to measure CBR.
· When no SL CBR measurement result is available, a (pre-)configured SL CBR value is used.
Working assumption
For UE performs partial sensing or random resource selection, Rel-16 SL CR evaluation is directly reused.
Agreement
For SL CBR measurement in partial sensing, select one option in the following:
· Option 1, 2, 3: SL RSSI is measured for slots in which the UE performs partial sensing and PSCCH/PSSCH reception over a SL CBR measurement window defined in Rel-16. The calculation of SL CBR is limited within the slots for which the SL RSSI is measured.
o If the number of SL RSSI measurement slots is below a (pre-)configured threshold, FFS the following or other options.
§ Option 1: a (pre-)configured SL CBR value is used.
§ Option 2: the UE additionally measure a set of slots within the SL CBR measurement window to meet the threshold.
§ Option 3: the UE measures an additional set of slots which can be extended outside the SL CBR measurement window to meet the threshold.
§ FFS whether the set of slots in option 2/3 are (pre-) configured or selected by UE implementation.
· Option 4: LTE principle is reused:
o The UE is not required to measure CBR.
o When no SL CBR measurement result is available, a (pre-)configured SL CBR value is used
Final summary in R1-2112528.
R1-2110845 Inter-UE coordination in sidelink resource allocation Huawei, HiSilicon
R1-2110862 Inter-UE coordination for Mode 2 enhancements Nokia, Nokia Shanghai Bell
R1-2110887 Discussion on techniques for inter-UE coordination FUTUREWEI
R1-2111037 Remaining issues on mode-2 enhancements vivo
R1-2111112 Discussion on inter-UE coordination in sidelink resource allocation Spreadtrum Communications
R1-2111151 Considerations on inter-UE coordination for mode 2 enhancements Fujitsu
R1-2111229 Remaining issues on Inter-UE coordination for Mode 2 enhancements CATT, GOHIGH
R1-2111301 Inter-UE coordination in mode 2 of NR sidelink OPPO
R1-2111354 Inter-UE coordination for mode 2 enhancements Zhejiang Lab
R1-2111407 Discussion on inter-UE coordination for Mode 2 enhancements Sony
R1-2111515 Design of Inter-UE Coordination Solutions for Sidelink Communication Intel Corporation
R1-2111547 Discussion on inter-UE coordination Xiaomi
R1-2111626 Discussion on inter-UE coordination for mode 2 enhancement CMCC
R1-2111650 Resource Allocation Enhancements for Mode 2 Fraunhofer HHI, Fraunhofer IIS
R1-2111657 Considerations on mode 2 enhancements CAICT
R1-2111667 Discussion on inter-UE coordination ZTE
R1-2111700 Discussion on mode 2 enhencements NEC
R1-2111759 On Inter-UE Coordination for Mode2 Enhancements Samsung
R1-2111816 Discussion on inter-UE coordination for Mode 2 enhancements LG Electronics
R1-2111825 On inter-UE coordination for Mode 2 enhancement InterDigital, Inc.
R1-2111827 Inter-UE coordination for enhanced resource allocation Mitsubishi Electric RCE
R1-2111895 Inter-UE Coordination Apple
R1-2111967 Inter-UE coordination for Mode 2 enhancements Panasonic Corporation
R1-2111998 Discussion on inter-UE coordination for Mode 2 enhancements ETRI
R1-2112025 Discussion on inter-UE coordination for mode 2 enhancements Sharp
R1-2112034 Inter-UE Coordination for NR SL Mode 2 Enhancement Convida Wireless
R1-2112043 Discussion on V2X mode 2 enhancements ASUSTeK
R1-2112127 Resource allocation for reliability and latency enhancements NTT DOCOMO, INC.
R1-2112165 Inter-UE coordination for Mode 2 enhancements Lenovo, Motorola Mobility
R1-2112577 Reliability and Latency Enhancements for Mode 2 Qualcomm Incorporated (rev of R1-2112238)
R1-2112318 Discussion on Mode 2 enhancements MediaTek Inc.
R1-2112352 Details on mode 2 enhancements for inter-UE coordination Ericsson
R1-2112396 Remaining details on mode 2 inter-UE coordination ROBERT BOSCH GmbH
[107-e-NR-R17-Sidelink-02] – Seungmin (LGE)
Email discussion on inter-UE coordination for mode 2 enhancements
- 1st check point: November 15
- Final check point: November 19
R1-2111817 Feature lead summary #1 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
R1-2111818 Feature lead summary #2 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Nov 15th GTW session
Proposal
candidate
single-slot resources, the resource set is indicated by
·
If 
is known by UE-B, the second sum term is omitted
R1-2111819 Feature lead summary #3 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Nov 17th GTW session
Agreement
A resource pool level (pre-)configuration uses either of the following options
· Option 1: PSFCH occasion is derived by a slot where UE-B’s SCI is transmitted
o Reuse PSSCH-to-PSFCH timing as specified in TS 38.213 Section 16.3 to determine the PSFCH occasion for resource conflict indication
o Time gap between the PSFCH and a slot where expected/potential resource conflict occurs is larger than or equal to T_3
o UE-A transmits the PSFCH in a latest slot that includes PSFCH resources for inter-UE coordination information and is at least T_3 slots of the resource pool before the PSSCH resource indicated by UE-B’s SCI in which expected/potential resource conflict occurs
o FFS: How to account for processing timeline
Note that it is possible not to configure either option1 or option 2.
Decision: As per email decision posted on Nov 18th,
Agreement
· For Condition 1-A-2 of Scheme 1, the set of resources preferred for UE-B’s transmission is a form of candidate single-slot resource as specified in Rel-16 TS 38.214 Section 8.1.4
o UE-A excludes candidate single-slot candidate(s) belonging to “slot(s) where UE-A, when it is intended receiver of UE-B, does not expect to perform SL reception from UE-B due to half duplex operation” after Step 6) of TS 38.214 Section 8.1.4
Agreement
When PSFCH TX/RX for Scheme 2 is overlapping with LTE SL TX/RX and/or UL in a UE, reuse prioritization rule as specified in TS 38.213 Section 16.2.4.1 and 16.2.4.3.1.
Conclusion
For Scheme 2, the values of the following parameters are the same as those for SL HARQ-ACK feedback in the same resource pool
· Period of PSFCH resources (sl-PSFCH-Period)
· Number of cyclic shift pairs used for a PSFCH transmission that can be multiplexed in a PRB (sl-NumMuxCS-Pair)
· Number of PSFCH resources available for multiplexing information in a PSFCH transmission (sl-PSFCH-CandidateResourceType)
R1-2112649 Feature lead summary #4 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements LG Electronics
From Nov 19th GTW session
Agreement
For Scheme 1, a resource pool level (pre-)configuration can enable one of the following alternatives:
· Alt 1 (Working Assumption): MAC CE or 2nd SCI are used as the container of inter-UE coordination information transmission from UE A to UE B.
o For the indication of resource set, the following is supported:
§ N combinations of TRIV, FRIV, resource reservation period as specified in Rel-16 TS 38.214 Section 8.1.5 with following modification. The value of resource reservation period is omitted at least when the transmission of preferred resource set is triggered by UE-B’s explicit request.
· First resource location of each TRIV is separately indicated by the inter-UE coordination information
§ If [N <= 3], MAC CE is used and it is up to UE implementation to additionally use 2nd SCI. When 2nd SCI and MAC CE are both used, the same resource set is indicated in the 2nd SCI and the MAC CE. If [N > 3], only MAC CE is used.
· FFS: UE capability details
· 2nd SCI is UE RX optional
· Alt 2: MAC CE is used as the container of inter-UE coordination information transmission from UE A to UE B.
o For the indication of resource set, the following is supported:
§ N combinations of TRIV, FRIV, resource reservation period as specified in Rel-16 TS 38.214 Section 8.1.5 with following modification. The value of resource reservation period is omitted at least when the transmission of preferred resource set is triggered by UE-B’s explicit request.
· First resource location of each TRIV is separately indicated by the inter-UE coordination information
· FFS: Whether/How to use resource reservation information as coordination information
Decision: As per email decision posted on Nov 20th,
Working Assumption
A resource pool level (pre-)configuration can enable one of the following options:
· Option 1:
o For Condition 2-A-1 of Scheme 2, support following additional criteria to determine resource(s) where expected/potential resource conflict occurs
§ For the case when UE-A is a destination UE of a TB transmitted by UE-B
· The resource(s) are fully/partially overlapping in time-and-frequency with other UE’s reserved resource(s) whose RSRP measurement is larger than a RSRP threshold according to the priorities included in the SCI:
o prio_TX and prio_RX are the priorities indicated in the SCI making the overlapping reservations for UE-B and other UE respectively
§ For the case when UE-A is a destination UE of a TB transmitted by another UE
· The resource(s) are fully/partially overlapping in time-and-frequency with other UE’s reserved resource(s) when RSRP measurement of UE-B’s reserved resource is larger than a RSRP threshold according to the priorities included in the SCI:
o prio_TX and prio_RX are the priorities indicated in the SCI making the overlapping reservations for other UE and UE-B respectively
· Option 4:
o For Condition 2-A-1 of Scheme 2, support following additional criteria to determine resource(s) where expected/potential resource conflict occurs
§ For the case when UE-A is a destination UE of a TB transmitted by UE-B
· The resource(s) are fully/partially overlapping in time-and-frequency with other UE’s reserved resource(s) whose RSRP measurement is larger than a (pre)configured RSRP threshold compared to the RSRP measurement of UE-B’s reserved resource.
§ For the case when UE-A is a destination UE of a TB transmitted by another UE
· The resource(s) are fully/partially overlapping in time-and-frequency with other UE’s reserved resource(s) when RSRP measurement of UE-B’s reserved resource is larger than a (pre)configured RSRP threshold compared to the RSRP measurement of the resource(s).
o Support of Option 4 is subject to UE capability
· FFS: Whether/how RSRP threshold depends on priority, MCS, overlap
Agreement
For Scheme 1 with non-preferred resource set,
· Physical layer at UE-B excludes in its resource (re-)selection, candidate single-slot resource(s) obtained after Step 6) of Rel-16 TS 38.214 Section 8.1.4 overlapping with the non-preferred resource set
Agreement
For Condition 1-A-1 of Scheme 1, when UE-A determines the set of resources preferred for UE-B’s transmission, apply RSRP threshold increase in the same way according to Rel-16 TS 38.214 Section 8.1.4.
· FFS: Whether/how to introduce the maximum limit of RSRP threshold increase
Agreement
For Scheme 1, at least following parameters are provided by UE-B’s request:
· Priority value to be used for PSCCH/PSSCH transmission
· Number of sub-channels to be used for PSSCH/PSCCH transmission in a slot
· Resource reservation interval
Agreement
For Scheme 2, when PSFCH occasion is derived by a slot where expected/potential resource conflict occurs on PSSCH resource indicated by UE-B’s SCI,
· Time gap between the PSFCH and SCI(s) scheduling conflicting TBs is larger than or equal to X value.
o FFS: Details of X
Working Assumption
For Condition 2-A-1 in Scheme 2, when “a non-destination UE of a TB transmitted by UE-B can be UE-A” is enabled or when “a non-destination UE of a TB transmitted by UE-B can be UE-A” is disabled and the destination UE of the conflicting TBs is UE-A, for each pair of UEs scheduling the conflicting TBs, a UE with the higher priority value is UE-B.
· FFS whether/how to set additional condition for UE-A to send PSFCH.
· Conclude on whether/how to handle, or differently handle, the case when at least one of UEs scheduling conflicting TBs doesn’t support Scheme 2 at the subsequent meetings
Agreement
For inter-UE coordination information triggered by an explicit request in Scheme 1,
· UE-A uses a TX resource pool used for UE-B’s request transmission to determine the set of resources and to transmit the set of resources to UE-B
Agreement
For inter-UE coordination information triggered by a condition rather than request reception in Scheme 1,
· UE-A transmitting in a resource pool provides inter-UE coordination information associated with the same resource pool
Final summary in R1-2112756.
R1-2111038 Other aspects on SL enhancements vivo
R1-2111548 Discussion on other design aspects for sidelink enhancement Xiaomi
R1-2111639 Other enhancements on power saving ZTE, Sanechips
R1-2111760 Discussion on Sidelink Enhancement Samsung
R1-2111826 On gNB-designated resources for inter-UE coordination and sensing in SL DRX InterDigital, Inc.
R1-2111896 Network Assisted Resource Selection Apple
R1-2111931 Physical layer impacts of sidelink DRX Huawei, HiSilicon
R1-2112353 Additional considerations on resource allocation for power saving and inter-UE coordination Ericsson
Please refer to RP-202846 for detailed scope of the WI. Please also refer to slide 3 of R1-2200001 for additional guidance for this e-meeting. Relevant incoming in R1-2200006, R1-2200007, R1-2200008.
[107bis-e-R17-RRC-Sidelink] – Seungmin (LGE)
Email discussion on Rel-17 RRC parameters for sidelink enhancement
- Email discussion to start on January 20 and end by January 25
R1-2200807 [107bis-e-R17-RRC-Sidelink] Summary of email discussion on Rel-17 RRC parameters for sidelink enhancement Moderator (LG Electronics)
Document is noted. For consolidation under 8 in [107bis-e-R17-RRC].
Including consideration of the impact of sidelink DRX, if any.
R1-2200015 Resource allocation for power saving Nokia, Nokia Shanghai Bell
R1-2200021 Power consumption reduction for sidelink resource allocation FUTUREWEI
R1-2200041 Sidelink resource allocation to reduce power consumption Huawei, HiSilicon
R1-2200091 Remaining issues on resource allocation for sidelink power saving vivo
R1-2200125 Considerations on partial sensing and DRX in NR Sidelink Fujitsu
R1-2200130 Remaining issues on sidelink resource allocation enhancements for power saving CATT, GOHIGH
R1-2200168 Discussion on resource allocation for power saving LG Electronics
R1-2200181 Discussion on sidelink resource allocation for power saving Sony
R1-2200189 Remaining issues on resource allocation for power saving InterDigital, Inc.
R1-2200210 On Resource Allocation for Power Saving Samsung
R1-2200224 Remaining Issues on Sidelink Resource Allocation for Power Saving Panasonic Corporation
R1-2200241 Discussion on sidelink resource allocation for power saving NTT DOCOMO, INC.
R1-2200281 Discussion on sidelink resource allocation for power saving Spreadtrum Communications
R1-2200306 Power Savings for Sidelink Qualcomm Incorporated
R1-2200347 Remaining issues on power saving RA OPPO
R1-2200359 Discussion on resource allocation for power saving ETRI
R1-2200384 Remaining Details of Sidelink Resource Allocation Schemes for UE Power Saving Intel Corporation
R1-2200425 On Remaining Issues of Sidelink Resource Allocation for Power Saving Apple
R1-2200436 Discussion on resource allocation for power saving ZTE, Sanechips
R1-2200449 Discussion on sidelink resource allocation enhancement for power saving xiaomi
R1-2200474 Sidelink resource allocation for power saving Lenovo, Motorola Mobility
R1-2200505 Discussion on resource allocation for power saving Sharp
R1-2200510 Discussion on resource allocation for power saving NEC
R1-2200523 Remaining issues on partial sensing and SL DRX impact ASUSTeK
R1-2200545 Resource allocation for sidelink power saving MediaTek Inc.
R1-2200593 Remaining issues on resource allocation for power saving CMCC
R1-2200629 NR Sidelink Resource Allocation for UE Power Saving Fraunhofer HHI, Fraunhofer IIS
R1-2200638 Remains on resource allocation for power saving in NR sidelink enhancement ITL
R1-2200641 Remaining aspects of resource allocation procedures for power saving Ericsson
[107bis-e-R17-Sidelink-01] – Kevin (OPPO)
Email discussion on resource allocation for power saving
- 1st check point: January 20
- Final check point: January 25
R1-2200720 FL summary #1 for AI 8.11.1.1 – resource allocation for power saving Moderator (OPPO)
From Jan 17th GTW session
R1-2200721 FL summary #2 for AI 8.11.1.1 – resource allocation for power saving Moderator (OPPO)
From Jan 18th GTW session
R1-2200722 FL summary #3 for AI 8.11.1.1 – resource allocation for power saving Moderator (OPPO)
From Jan 19th GTW session
Agreement
When UE is configured to perform partial sensing by a UE higher layer (including when SL DRX is configured), SL RSSI is measured in slots where the UE performs partial sensing and PSCCH/PSSCH reception over the SL CBR measurement window defined in Rel-16. The calculation of SL CBR is limited within the slots for which the SL RSSI is measured.
· If the number of SL RSSI measurement slots is below a (pre-)configured threshold, a (pre-)configured SL CBR value is used.
R1-2200723 FL summary #4 for AI 8.11.1.1 – resource allocation for power saving Moderator (OPPO)
From Jan 20th GTW session
Agreement
When UE is triggered to perform re-evaluation and pre-emption checking for aperiodic transmission (Prsvp_TX=0) in slot n,
·
The candidate resource set
(SA) is initialized to the remaining Y’ candidate
slots that starts from
slot 
and ends at the last slot of the Y’ candidate slots.
o
is the first candidate slot after slot n+T3.
· UE may perform PBPS for periodic sensing occasions after the resource (re)selection when sl-MultiReserveResource is enabled for the mode 2 Tx resource pool
o It is up to UE implementation
·
UE performs CPS starting
from at least M consecutive logical slots earlier than to 
slots earlier than 
.
o FFS: When the minimum M slots for CPS cannot be guaranteed,
· All available sensing results not earlier than n–T0 for the resource pool indicated by higher layer are applied for re-evaluation and pre-emption checking procedures
From Jan 21st GTW session
Agreement
When UE performs at least contiguous partial sensing in a mode 2 Tx pool for a resource (re)selection procedure and re-evaluation/pre-emption checking triggered by aperiodic transmission (Prsvp_TX=0) in slot n,
· For minimum size M of the CPS monitoring window [n+TA, n+TB]:
o By default, M is 31 unless (pre-)configured with another value
o The range of (pre-)configured M is from 0 (working assumption) to 30
R1-2200786 FL summary #5 for AI 8.11.1.1 – resource allocation for power saving Moderator (OPPO)
From Jan 25th GTW session
Agreement
When UE performs only contiguous partial sensing (CPS) in a mode 2 Tx pool with periodic reservation for another TB (sl-MultiReserveResource) disabled, and a resource (re)selection is triggered in slot n,
· T1 is defined based on step 1) of Rel-16 TS 38.214 Sec. 8.1.4.
o No update to specification is necessary due to this agreement
· Note: The selected Y’ slots do not overlap with the sensing window
Agreement
Whether UE performs SL reception of PSCCH and RSRP measurement for partial sensing on slots in SL DRX inactive time is enabled/disabled by (pre-)configuration per resource pool when partial sensing is configured in the UE by a higher layer.
· When it is enabled,
o When UE performs periodic-based partial sensing for a given Preserve, UE monitors only the default periodic sensing occasion.
o When UE performs contiguous partial sensing, UE monitors a minimum of M slots for CPS.
· Note, when it is disabled, the UE is not required to perform SL reception of PSCCH and RSRP measurement in SL DRX inactive time.
· Note: no further optimization on the resource (re)selection procedure with regard to SL DRX operation is specified in Rel.17.
· FFS the case when full sensing is configured in the UE by a higher layer
Final summary in R1-2200724.
R1-2200016 Inter-UE coordination for Mode 2 enhancements Nokia, Nokia Shanghai Bell
R1-2200022 Discussion on techniques for inter-UE coordination FUTUREWEI
R1-2200042 Inter-UE coordination in sidelink resource allocation Huawei, HiSilicon
R1-2200092 Remaining issues on mode-2 enhancements vivo
R1-2200126 Considerations on inter-UE coordination for mode 2 enhancements Fujitsu
R1-2200131 Remaining issues on Inter-UE coordination for Mode 2 enhancements CATT, GOHIGH
R1-2200169 Discussion on inter-UE coordination for Mode 2 enhancements LG Electronics
R1-2200182 Discussion on inter-UE coordination for Mode 2 enhancements Sony
R1-2200190 Discussions on remaining issues for Mode 2 inter-UE coordination InterDigital, Inc.
R1-2200211 On Inter-UE Coordination for Mode2 Enhancements Samsung
R1-2200225 Inter-UE coordination for mode 2 enhancements ITL
R1-2200242 Resource allocation for reliability and latency enhancements NTT DOCOMO, INC.
R1-2200270 Considerations on mode2 enhancements CAICT
R1-2200282 Discussion on inter-UE coordination in sidelink resource allocation Spreadtrum Communications
R1-2200307 Reliability and Latency Enhancements for Mode 2 Qualcomm Incorporated
R1-2200348 Inter-UE coordination in mode 2 of NR sidelink OPPO
R1-2200360 Discussion on inter-UE coordination for Mode 2 enhancements ETRI
R1-2200361 Inter-UE coordination for enhanced resource allocation Mitsubishi Electric RCE
R1-2200385 Inter-UE Coordination Solutions for Sidelink Communication Intel Corporation
R1-2200426 On Remaining Issues of Inter-UE Coordination Apple
R1-2200437 Remaining issues on the inter-UE coordination ZTE, Sanechips
R1-2200450 Discussion on inter-UE coordination xiaomi
R1-2200475 Inter-UE coordination for Mode 2 enhancements Lenovo, Motorola Mobility
R1-2200504 Discussion on inter-UE coordination for mode 2 enhancements Sharp
R1-2200511 Discussion on mode 2 enhancements NEC
R1-2200524 Remaining issues on V2X mode 2 enhancements ASUSTeK
R1-2200554 Discussion on Mode 2 enhancements MediaTek Inc.
R1-2200594 Remaining issues on inter-UE coordination for mode 2 enhancement CMCC
R1-2200630 Inter-UE Coordination for Mode 2 Enhancements Fraunhofer HHI, Fraunhofer IIS
R1-2200642 Details on mode 2 enhancements for inter-UE coordination Ericsson
R1-2200675 Inter-UE coordination for Mode 2 enhancements Panasonic
[107bis-e-R17-Sidelink-02] – Seungmin (LGE)
Email discussion on inter-UE coordination for mode 2 enhancements
- 1st check point: January 20
- Final check point: January 25
R1-2200170 Feature lead summary #1 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Jan 17th GTW session
Agreement
· For Scheme 1, when the inter-UE coordination information transmission is triggered by UE-B’s explicit request,
o Starting/Ending time locations of resource selection window is provided by UE-B’s explicit request
§ Starting/Ending time locations of resource selection window is a form of combination of DFN index and slot index
R1-2200171 Feature lead summary #2 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Jan 18th GTW session
Agreement
· When PSFCH occasion is derived by a slot where expected/potential resource conflict occurs on PSSCH resource indicated by UE-B’s SCI, time gap between the PSFCH and SCI(s) scheduling conflicting TBs is larger than or equal to X value
o X = sl-MinTimeGapPSFCH
· UE does not transmit the conflict indicator or receive the conflict indicator if the timeline is not satisfied
R1-2200172 Feature lead summary #3 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Jan 19th GTW session
Agreement
For Scheme 1, a resource pool level (pre-)configuration can enable one of the following alternatives:
· (working assumption) Alt1: MAC CE and 2nd SCI are used as the container of an explicit request transmission from UE-B to UE-A
o A single format SCI 2-C is used for inter-UE coordination information and request
§ 1 bit in format 2-C is used to indicate whether the SCI is used for request to coordination information or for conveying coordination information
o SCI 2-C is UE RX optional
o It is up to UE implementation to additionally use 2nd SCI (for UE-B).
· Alt2: MAC CE is used as the container of an explicit request transmission from UE-B to UE-A
R1-2200745 Feature lead summary #4 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Jan 20th GTW session
Conclusion
· For Scheme 2, there is no consensus to support indication of the following
o Condition type of a resource conflict
o Time location of a resource conflict
Agreement
For Scheme 2,
· The PHY layer reports S_A after Step 7) of TS 38.214 Section 8.1.4 to higher layer.
· When UE-B receives a conflict indicator for resource(s) indicated by its SCI,
o PHY layer at UE-B reports resources overlapping with the next reserved resource indicated by the corresponding UE-B’s SCI for current TB transmission to higher layer.
§ If (pre)configured, the PHY layer reports resources in a slot including the next reserved resource indicated by the corresponding UE-B’s SCI for current TB transmission to higher layer.
o Higher layer at UE-B re-selects the resource(s) indicated by the conflict indicator among the S_A excluding the reported resources.
· FFS: Whether/How the conflict in periodic transmission is indicated by UE-A and handled by UE-B
Agreement
· For PSFCH TX/RX or TX/TX prioritization in Scheme 2,
o Priority value of PSFCH TX for a resource conflict indication is the smallest priority value of the conflicting TBs
o Priority value of PSFCH RX for a resource conflict indication is priority value indicated by UE-B’s SCI
o For PSFCH TX/RX or TX/TX prioritization between SL HARQ-ACK feedback(s) and resource conflict indication(s), PSFCH TX/RX for SL HARQ-ACK feedback is always prioritized over PSFCH TX/RX for a resource conflict indication
R1-2200746 Feature lead summary #5 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Jan 21st GTW session
Agreement
For Scheme 1,
· Unicast is supported for an explicit request transmission for inter-UE coordination information
o Unicast is used for the inter-UE coordination information transmission triggered by the explicit request
Working Assumption
For Scheme 1,
· Following cast type(s) are supported for inter-UE coordination information transmission triggered by a condition other than explicit request reception
o Groupcast/Broadcast for non-preferred resource set, FFS for preferred resource set
§ FFS: Under which conditions groupcast/broadcast can be supported
o Unicast
§ FFS: Under which conditions unicast can be supported
R1-2200747 Feature lead summary #6 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Jan 24st GTW session
Agreement
· For determining preferred resource set in Scheme 1, the value of Cresel is determined by UE-A according to Rel-16 procedure.
o This information is not conveyed to/from UE-B
o When inter-UE coordination information is triggered by UE-B’s request, P_rsvp_TX used for determining SL_RESOURCE_RESELECTION_COUNTER according to Rel-16 procedure is provided by resource reservation interval indicated by UE-B’s request.
Agreement
For the indication of resource set in Scheme 1, the value of Sl-MaxNumPerReserve is fixed to 3.
Agreement
The following working assumption is confirmed with modification in RED.
· MAC CE or 2nd SCI are used as the container of inter-UE coordination information transmission from UE A to UE B.
o For the indication of resource set, the following is supported:
§ N combinations of TRIV, FRIV, resource reservation period as specified in Rel-16 TS 38.214 Section 8.1.5 with following modification. The value of resource reservation period is omitted at least when the transmission of preferred resource set is triggered by UE-B’s explicit request.
· First resource location of each TRIV is separately indicated by the inter-UE coordination information
§ If [N <= 3], MAC CE is used and it is up to UE implementation to additionally use 2nd SCI. When 2nd SCI and MAC CE are both used, the same resource set is indicated in the 2nd SCI and the MAC CE. If [N > 3], only MAC CE is used.
· FFS: UE capability details
· 2nd SCI is UE RX optional
· The field size of the indication of resource set in a SCI format 2-C is determined by [N=3]
Agreement
· For inter-UE coordination information transmission in Scheme 1,
o Inter-UE coordination information can be multiplexed with other data only if the source/destination ID pair is the same
§ Retransmission of the TB carrying inter-UE coordination information is supported
· For explicit request transmission in Scheme 1,
o Explicit request can be multiplexed with other data only if the source/destination ID pair is the same
§ Retransmission of the TB carrying request is supported
Agreement
·
For inter-UE coordination triggered by an
explicit request in Scheme 1, whether or not to transmit the inter-UE
coordination information upon the request reception is determined by UE-A’s implementation subject to at least following
procedures.
o Rel-16 procedure of UL/SL prioritization, LTE SL/NR SL prioritization, and congestion control
R1-2200748 Feature lead summary #7 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Jan 25th GTW session
Agreement
· For inter-UE coordination triggered by a condition rather than request reception in Scheme 1,
o A resource pool level (pre-)configuration can enable one of the following alternatives:
§ Alt 1: it is up to UE-A’s implementation whether or not to trigger the inter-UE coordination information generation.
§ Alt 2: the inter-UE coordination information generation can be triggered only when UE-A has data to be transmitted together with the inter-UE coordination information to UE-B
o Note: Rel-16 procedure of UL/SL prioritization, LTE SL/NR SL prioritization, and congestion control is applied to the transmission of the inter-UE coordination information triggered by a condition.
Agreement
· For inter-UE coordination triggered by UE-B’s explicit request in Scheme 1,
o A resource pool level (pre-)configuration can enable one of the following alternatives:
§ Alt 1: it is up to UE-B’s implementation whether or not to trigger the request generation
§ Alt 2: the request generation can be triggered only when UE-B has data to be transmitted to UE-A
o Note: Rel-16 procedure of UL/SL prioritization, LTE SL/NR SL prioritization, and congestion control is applied to the transmission of the request transmission.
Agreement
· For Scheme 1 with preferred resource set Option A,
o MAC layer selects resources using S_A and the received preferred resource set
§ MAC layer firstly selects resources for transmissions within the intersection of S_A and the preferred resource set until it becomes impossible to select a resource within the intersection under the constraint defined in Rel-16.
· It is up to the UE whether to use the preferred resource set from SCI format 2-C and/or MAC CE
o After this, if the number of selected resources is smaller than the required number of transmissions for a TB, MAC layer selects resources for the remaining transmissions outside the intersection but inside S_A under the constraint defined in Rel-16.
Agreement
· For Scheme 1 with preferred resource set Option B,
o MAC layer selects resources belonging to the received preferred resource set under the constraint defined in Rel-16
§ It is up to the UE whether to use the preferred resource set from SCI format 2-C and/or MAC CE
Agreement
· For inter-UE coordination information triggered by an explicit request in Scheme 1, the priority value of the inter-UE coordination information is (pre)configured priority value if it is provided by (pre)configuration. Otherwise, the priority value is the same as indicated by UE-B’s explicit request.
o For the case when inter-UE coordination information is transmitted together with other data, the priority value of the multiplexed sidelink transmission is determined by the smallest priority value between the inter-UE coordination information and data
Agreement
· For inter-UE coordination information triggered by an explicit request in Scheme 1, the priority value of explicit request is (pre)configured priority value if it is provided by (pre)configuration. Otherwise, the priority value is the same as that of a TB to be transmitted by UE-B.
o For the case when the explicit request is transmitted together with other data, the priority value of the multiplexed sidelink transmission is determined by the smallest priority value between the explicit request and data
Agreement
· For inter-UE coordination information triggered by a condition other than explicit request reception in Scheme 1, the priority value of the inter-UE coordination information is (pre)configured priority value if it is provided by (pre)configuration.
o FFS: Otherwise, the priority value is determined by UE-A’s implementation.
o For the case when inter-UE coordination information is transmitted together with other data, the priority value of the multiplexed sidelink transmission is determined by the smallest priority value between the inter-UE coordination information and data
Decision: As per email decision posted on Jan 26th,
Agreement
· For sidelink transmission carrying inter-UE coordination information in Scheme 1,
o UE-A performs its resource (re)selection according to the same procedure in TS 38.214 Section 8.1.4 to transmit the inter-UE coordination information to UE-B.
· For sidelink transmission carrying request in Scheme 1,
o UE-B performs its resource (re)selection according to the same procedure in TS 38.214 Section 8.1.4 to transmit the request for the inter-UE coordination information to UE-A if UE-B performs sensing/resource exclusion. Otherwise, at least UE-B can perform random selection
· Note: RAN1 does not pursue specific enhancement of Rel-17 resource (re)selection for the transmission of inter-UE coordination information and its request.
Working assumption
· First resource location of each TRIV is a slot offset with respect to a reference slot
o Alt 2:
§ The slot offset is the number of logical slots from the reference slot
· The value range of slot offsets is from 0 to maximum value that is (pre)configurable up to [256]
o FFS: The detailed value range including granularity
· Slot offset for each TRIV to indicate the set of resources is separately indicated by inter-UE coordination information
§ For the reference slot,
· The reference slot is the slot indicated by the inter-UE coordination information in a form of combination of DFN index and slot index
Agreement
· For determining preferred resource set in Scheme 1, when inter-UE coordination information transmission is triggered by a condition other than explicit request reception,
o Values of following parameters are (pre)configured for a resource pool. If there is no (pre)configuration, UE-A determines by its implementation the values of the following parameters
§ prio_TX
§ L_subCH
§ P_rsvp_TX
o UE-A determines by its implementation values of following parameters
§ n+T_1, n+T_2
o FFS: Whether/how to support (pre)configuration of n+T_1 and n+T_2
o Note that it is up to RAN2 decision whether/how the values of these parameters are provided by PC5-RRC signaling from UE-B to UE-A and UE-A uses the received information to determine the preferred resource set
Agreement
· For inter-UE coordination information is triggered by UE-B’s request,
o A resource pool level (pre-)configuration can enable one of the following alternatives:
§ Alt 1:
· Resource set type to be provided by inter-UE coordination information transmission is determined by UE-A’s implementation and its information is indicated by UE-A’s inter-UE coordination information
o UE-A’s inter-UE coordination information indicates either preferred resource set or non-preferred resource set
§ Alt 2:
· Resource set type to be provided by inter-UE coordination information transmission is indicated by UE-B’s request
o UE-B’s request indicates either preferred resource set or non-preferred resource set
o Note that it is up to RAN2 decision whether/how UE-B provides its support of sensing/resource exclusion to UE-A via PC5-RRC signaling and UE-A uses the received information to determine the type of resource set to be transmitted to UE-B
Agreement
· For inter-UE coordination information is triggered by a condition other than explicit request reception,
o Resource set type to be provided by inter-UE coordination information transmission is determined by UE-A’s implementation and its information is indicated by UE-A’s inter-UE coordination information
§ UE-A’s inter-UE coordination information indicates either preferred resource set or non-preferred resource set
Working assumption
· For Scheme 2, (pre)configuration is supported to enable or disable that 1 LSB of reserved bits of a SCI format 1-A is used to indicate of whether UE scheduling a conflict TB can be UE-B or not.
o FFS: UE-A's behavior for the case when at least one of UEs scheduling conflicting TBs is not capable of receiving the conflict indication
Final summary in R1-2200749.
R1-2200093 Other aspects on SL enhancements vivo
R1-2200132 Discussion on the status of Rel-17 Sidelink enhancements CATT, GOHIGH
R1-2200191 On gNB-designated resources for inter-UE coordination and sensing in SL DRX InterDigital, Inc.
R1-2200212 Discussion on Sidelink Enhancement Samsung
R1-2200439 Other enhancements on power saving ZTE, Sanechips
R1-2200643 Additional considerations on resource allocation regarding power saving and inter-UE coordination Ericsson
R1-2200651 Physical layer impacts of sidelink DRX Huawei, HiSilicon
Please refer to RP-202846 for detailed scope of the WI. Please also refer to slide 4 of RP-213660 for additional guidance for this e-meeting.
[108-e-R17-RRC-Sidelink] – Seungmin (LGE)
Email discussion on Rel-17 RRC parameters for sidelink enhancement
- 1st check point for first LS in [108-e-R17-RRC]: February 24
- Final check point for second LS in [108-e-R17-RRC] if necessary: March 3
R1-2202708 [108-e-R17-RRC-Sidelink] Summary of email discussion on Rel-17 RRC parameters for sidelink enhancement Moderator (LG Electronics)
Document is noted. For consolidation under 8 in [108-e-R17-RRC].
Including consideration of the impact of sidelink DRX, if any.
R1-2200963 Sidelink resource allocation to reduce power consumption Huawei, HiSilicon
R1-2200980 Resource allocation for power saving Nokia, Nokia Shanghai Bell
R1-2200982 Power consumption reduction for sidelink resource allocation FUTUREWEI
R1-2201111 Remaining issues on resource allocation for sidelink power saving vivo
R1-2201254 Remaining essential issues on power saving RA OPPO
R1-2201335 Remaining issues on sidelink resource allocation enhancements for power saving CATT, GOHIGH
R1-2201386 Remaining Issues on Sidelink Resource Allocation for Power Saving Panasonic Corporation
R1-2201437 Discussion on partial sensing and DRX in NR Sidelink Fujitsu
R1-2201494 Remaining issues on sidelink resource allocation for power saving NTT DOCOMO, INC.
R1-2201530 Remaining issues on resource allocation for power saving InterDigital, Inc.
R1-2201557 Discussion on sidelink resource allocation for power saving Spreadtrum Communications
R1-2201584 Discussion on sidelink resource allocation for power saving Sony
R1-2201616 Discussion on resource allocation for power saving ETRI
R1-2201715 Remaining opens of sidelink resource allocation schemes for UE power saving Intel Corporation
R1-2201784 Remaining Issues of Sidelink Resource Allocation for Power Saving Apple
R1-2201819 Remaining issues on partial sensing and SL DRX impact ASUSTeK
R1-2201873 Remaining issues on resource allocation for power saving CMCC
R1-2201906 Discussion on resource allocation for power saving NEC
R1-2201929 Discussion on sidelink resource allocation enhancement for power saving Xiaomi
R1-2202031 On Resource Allocation for Power Saving Samsung
R1-2202063 Resource allocation for sidelink power saving MediaTek Inc.
R1-2202158 Power Savings for Sidelink Qualcomm Incorporated
R1-2202201 Discussion on resource allocation for power saving Sharp
R1-2202230 Sidelink resource allocation for power saving Lenovo, Motorola Mobility
R1-2202252 Discussion on resource allocation for power saving LG Electronics
R1-2202262 Remaining aspects of resource allocation procedures for power saving Ericsson
R1-2202373 Remains on resource allocation for power saving in NR sidelink enhancement ITL
R1-2202376 Discussion on resource allocation for power saving ZTE, Sanechips
R1-2202376 Discussion on resource allocation for power saving ZTE, Sanechips
R1-2202482 Resource allocation for power saving Fraunhofer HHI
[108-e-R17-Sidelink-01] – Kevin (OPPO)
Email discussion on resource allocation for power saving
- 1st check point: February 25
- Final check point: March 3
R1-2202561 FL summary #1 for AI 8.11.1.1 – NR sidelink resource allocation for power saving Moderator (OPPO)
From Feb 22nd GTW session
Agreement
The lower bound of M value for CPS in the case of periodic transmission (contiguousSensingWindowPeriodic) for both resource (re)selection and re-evaluation / pre-emption checking is a non-zero value (lower bound for M is 5)
Note: CATT indicated that they do not agree to the technical benefits of this agreement
Agreement
When a UE is triggered to perform re-evaluation and pre-emption checking for aperiodic transmission (Prsvp_TX=0) in slot n and the minimum M slots for CPS cannot be guaranteed,
·
UE senses in all available
slots starting from the resource (re)selection
trigger slot of the same TB to 
slots earlier than 
.
o The UE re-evaluation and pre-emption checking is based on all available sensing results after n-T0
R1-2202562 FL summary #2 for AI 8.11.1.1 – NR sidelink resource allocation for power saving Moderator (OPPO)
From Feb 24th GTW session
Proposal
When UE performs random resource selection in a resource pool (pre-)configured with full/partial sensing and random resource selection,
· Option 1: A priority threshold value is (pre-)configured for the resource pool, below or equal to which random resource selection is allowed. The (pre-)configured priority threshold can be any of the 8 priority values.
o Note 1, lower value means higher priority.
o Note 2, resource pool partitioning is not supported for this case
Objected by Samsung, Nokia/NSB, Xiaomi
Conclusion
The existing Step 5 and 5a are applicable for UE configured for partial sensing by its higher layer.
R1-2202563 FL summary #3 for AI 8.11.1.1 – NR sidelink resource allocation for power saving Moderator (OPPO)
From Mar 2nd GTW session
Possible Agreement
When SL DRX active time of RX UE is provided by the higher layer for candidate resource selection
·
Solution 6 (compromised):
If there are less than Z candidate single-slot resources remained within
the indicated SL DRX active time in the set SA after
completing the iterations from step 4) to 7) to fulfil 
, for the reported subset of the candidate resources, the UE applies the RSRP threshold increment in Step
7 and continues the procedure from step 4)
to 7) only for resources within
the SL DRX active time with replacing 
by Z, where Z is determined by
UE implementation within a range of 0 < Z
≤ 
and 
is the total number of candidate single-slot
resources within the SL DRX active time of the initialized set SA in Step 4).
Sustained objection: CATT, ZTE
R1-2202564 FL summary #4 for AI 8.11.1.1 – NR sidelink resource allocation for power saving Moderator (OPPO)
From Mar 3rd GTW session
Agreement
In Step 6 c) of TS38.214 Section 8.1.4, when UE is configured with partial sensing by its higher layer, adopt the following changes:
·
if slot 
belongs to the set 
, otherwise, slot 
is the first slot after slot 
belonging to the set 
.
·
Option D: 
converted to milliseconds, where slot 
is the last slot of the Y or Y’ candidate slots.
·
Slot 
is the first slot of the selected/remaining set of Y or Y’
candidate slots.
Final summary in R1-2202565.
R1-2200964 Inter-UE coordination in sidelink resource allocation Huawei, HiSilicon
R1-2200981 Inter-UE coordination for Mode 2 enhancements Nokia, Nokia Shanghai Bell
R1-2200983 Discussion on techniques for inter-UE coordination FUTUREWEI
R1-2201112 Remaining issues on mode-2 enhancements vivo
R1-2201182 Inter-UE coordination for Mode 2 enhancements Panasonic Corporation
R1-2201255 Inter-UE coordination in mode 2 of NR sidelink OPPO
R1-2201336 Remaining issues on Inter-UE coordination for Mode 2 enhancements CATT, GOHIGH
R1-2201438 Discussion on inter-UE coordination for Mode 2 enhancements Fujitsu
R1-2201495 Remaining issues on sidelink resource allocation for reliability and latency NTT DOCOMO, INC.
R1-2201531 Discussions on remaining issues for Mode 2 inter-UE coordination InterDigital, Inc.
R1-2201558 Discussion on inter-UE coordination in sidelink resource allocation Spreadtrum Communications
R1-2201585 Discussion on inter-UE coordination for Mode 2 enhancements Sony
R1-2201617 Discussion on inter-UE coordination for Mode 2 enhancements ETRI
R1-2201716 Remaining opens of sidelink inter-UE coordination schemes Intel Corporation
R1-2201785 Remaining Issues of Inter-UE Coordination Apple
R1-2201820 Remaining issues on V2X mode 2 enhancements ASUSTeK
R1-2201874 Remaining issues on inter-UE coordination for mode 2 enhancement CMCC
R1-2201907 Discussion on mode 2 enhancements NEC
R1-2201920 Discussion on inter-UE coordination Xiaomi
R1-2202032 On Inter-UE Coordination for Mode2 Enhancements Samsung
R1-2202086 Discussion on Mode 2 enhancements MediaTek Inc.
R1-2202159 Reliability and Latency Enhancements for Mode 2 Qualcomm Incorporated
R1-2202202 Discussion on inter-UE coordination for mode 2 enhancements Sharp
R1-2202231 Inter-UE coordination for Mode 2 enhancements Lenovo, Motorola Mobility
R1-2202245 Inter-UE coordination for mode 2 enhancements ITL
R1-2202253 Discussion on inter-UE coordination for Mode 2 enhancements LG Electronics
R1-2202263 Details on mode 2 enhancements for inter-UE coordination Ericsson
R1-2202356 Inter-UE coordination for enhanced resource allocation Mitsubishi Electric RCE
R1-2202377 Remaining issues on the inter-UE coordination ZTE, Sanechips
R1-2202483 Inter-UE coordination for Mode 2 enhancements Fraunhofer HHI
[108-e-R17-Sidelink-02] – Seungmin (LGE)
Email discussion on inter-UE coordination for mode 2 enhancements
- 1st check point: February 25
- Final check point: March 3
R1-2202254 Feature lead summary #1 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Feb 21st GTW session
Agreement
· For a slot offset that is (pre)configured to indicate the first resource location of each TRIV with respect to a reference slot,
o Granularity of the slot offset is 1 logical slot
o (Pre)configured maximum value of the slot offset is up to 8000
§ When both SCI format 2-C and MAC CE are used as the container of inter-UE coordination information, the maximum value of the slot offset is 255
§ When MAC CE only is used as the container of inter-UE coordination information, the maximum value of the slot offset is the (pre)configured maximum value
Agreement
A SCI format 2-C includes all the fields present in SCI format 2-A except cast type indicator.
Conclusion
· For cast type(s) of inter-UE coordination information with preferred resource set triggered by a condition other than explicit request reception, there is no consensus in RAN1 on the support of groupcast or broadcast for preferred resource set.
R1-2202255 Feature lead summary #2 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Feb 23rd GTW session
Agreement
For Scheme 2, m_CS for a resource conflict indication for the next reserved resource indicated by the corresponding UE-B’s SCI for either current TB transmission or next TB transmission is 0.
Agreement
For Scheme 2, when UE-B receives a conflict indicator for resource(s) indicated by its SCI, it up to UE-B’s implementation whether/how to set the reservation periodicity in the re-selected resource.
Agreement
For Scheme 2,
· m_0 for a resource conflict indication is derived in the same way as specified for HARQ-ACK information in TS 38.213 Section 16.3.
· A UE expects that different PRBs are (pre)configured between conflict indication and HARQ-ACK information.
Decision: As per email decision posted on Feb 24th,
Agreement
For Scheme 1, when both SCI format 2-C and MAC CE are used as the container of an explicit request for inter-UE coordination information, the same bit field size for the request in a SCI format 2-C is applied to MAC CE.
Agreement
For Scheme 1, when MAC CE only is used as the container of an explicit request for inter-UE coordination information, the same bit field size for the request in a SCI format 2-C is applied to MAC CE
Conclusion
For inter-UE coordination operation in Rel-17, RAN1 understands that only UE(s) in mode 2 can be UE-A
· Note that RAN1 does not pursue specific enhancement of Rel-17 inter-UE coordination operation for handling the case where UE(s) in mode 1 can be UE-A
R1-2202256 Feature lead summary #3 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Feb 25th GTW session
Agreement
Confirm the following working assumption with modification in RED
|
Working assumption made in RAN1#107bis-e: First resource location of each TRIV is a slot offset with respect to a reference slot - Alt 2: o The slot offset is the number of logical slots from the reference slot §
The value range of
slot offsets is from 0 to maximum value that is (pre)configurable up to ·
§ Slot offset for each TRIV except for first TRIV to indicate the set of resources is separately indicated by inter-UE coordination information · Slot offset for first TRIV is 0 - For the reference slot, o The reference slot is the slot indicated by the inter-UE coordination information in a form of combination of DFN index and slot index |
Agreement
MAC CE or 2nd SCI are used as the container of inter-UE coordination information transmission from UE A to UE B.
· For the indication of resource set, the following is supported:
o N combinations of TRIV, FRIV, resource reservation period as specified in Rel-16 TS 38.214 Section 8.1.5 with following modification. The value of resource reservation period is omitted at least when the transmission of preferred resource set is triggered by UE-B’s explicit request.
§ First resource location of each TRIV is separately indicated by the inter-UE coordination information
o If N <= 2, MAC CE is used and it is up to UE implementation to additionally use 2nd SCI. When 2nd SCI and MAC CE are both used, the same resource set is indicated in the 2nd SCI and the MAC CE. If N > 2, only MAC CE is used.
§ FFS: UE capability details
§ 2nd SCI is UE RX optional
§ The field size of the indication of resource set in a SCI format 2-C is determined by N=2
Agreement
For Scheme 1, each bit field size of a SCI format 2-C for inter-UE coordination information is given by following table:
· Note that lowest subchannel index for the first resource location of each TRIV is separately indicated by inter-UE coordination information
|
Field name |
Field size (in bits) |
|
Providing/requesting indicator |
1 |
|
Resource combination(s) |
Where
|
|
First resource location(s) |
8 |
|
Reference slot location |
Where |
|
Resource set type |
1 |
|
Lowest subchannel indices for the first resource location of each TRIV |
where |
|
(FFS) Actual number of resource combination |
1 Note: Support of this field is to be concluded by Feb 28. |
Agreement
For Scheme 1, each bit field size of a SCI format 2-C for an explicit request for inter-UE coordination information is given by following table:
|
Field name |
Field size (in bits) |
|
Providing/requesting indicator |
1 |
|
Priority |
3 |
|
Number of subchannels |
Where |
|
Resource reservation period |
Where |
|
Resource selection window location |
Where |
|
Resource set type |
1 bit if determineResourceSetTypeScheme1 is set to ‘UE-B’s request’, otherwise, 0 bit |
This agreement does not imply that new field requested by RAN2 cannot be further added.
Agreement
For Scheme 1, when MAC CE only is used as the container of inter-UE coordination information, each bit field size for inter-UE coordination information is given by following table from RAN1’s perspective, and RAN1 understands that the maximum value of N resource combinations to be conveyed in inter-UE coordination information is bounded so that the total payload size of inter-UE coordination information leads not to exceed the size of TB including the MAC CE
· Details (e.g., whether/how to separately indicate the value of N in the inter-UE coordination information, how to put the following fields into MAC CE and the related field sizes in MAC CE) are up to RAN2
|
Field name |
Field size (in bits) |
|
Providing/requesting indicator |
1 |
|
Resource combination(s) |
Where
|
|
First resource location(s) |
Where X is provided by the (pre)configured maximum value of slot offset for the case when MAC CE only is used as a container of inter-UE coordination information |
|
Reference slot location |
Where |
|
Resource set type |
1 |
|
Lowest subchannel indices for the first resource location of each TRIV |
Where |
R1-2202257 Feature lead summary #4 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Mar 1st GTW session
Conclusion
There is no consensus in RAN1 on indicating actual number of resource combination in a SCI format 2-C for inter-UE coordination information.
· Note: Different resource combinations can indicate the same set of resources for the case when only one resource combination is actually used
Agreement
For Scheme 2,
Agreement
Confirm the following working assumption with modification in RED. Note that the terminology of “indicationUEB flag” means the indication of whether UE scheduling a conflict TB can be UE-B or not.
Agreement
A UE performs PSFCH TX/RX or TX/TX prioritization between SL HARQ-ACK feedback(s) and resource conflict indication(s) first, and then the UE performs prioritization between prioritized PSFCH TX(s) or RX(s) and LTE SL TX/RX or UL by reusing prioritization rule as specified in TS 38.213 Section 16.2.4.1 and 16.2.4.3.1.
Conclusion
RAN1 does not pursue specific enhancement of Rel-17 inter-UE coordination operation for handling the overlapping between UL with SL-HARQ-ACK information and PSFCH for a conflict indication, i.e., there is no case in Rel-17 where the overlapping between UL with SL-HARQ-ACK information and PSFCH for a conflict indication occur at a UE performing inter-UE coordination operation
Conclusion
There is no consensus in RAN1 to further introduce enhancement in Rel-17 on Mode 2 resource selection procedure to ensure the timeline (i.e., minimum time gap between PSFCH and a slot where a SCI is transmitted of sl-MinTimeGapPSFCH, minimum time gap between PSFCH and a slot where expected/potential resource conflict occurs on PSSCH resource indicated by a SCI of T_3) for a conflict indication.
Agreement
For Scheme 1, when both SCI format 2-C and MAC CE are used as the container of inter-UE coordination information, the same inter-UE coordination information is indicated in the SCI format 2-C and the MAC CE
· Details (e.g., how to put the fields of SCI format 2C for inter-UE coordination information into MAC CE and the related field sizes in MAC CE) are up to RAN2
Decision: As per email decision posted on Mar 1st,
Conclusion
When PSFCH occasion is derived by a slot where UE-B’s SCI is transmitted,
· if there is a PSFCH occasion satisfying “the minimum time gap (sl-MinTimeGapPSFCH) between the PSFCH occasion and a slot where the SCI is transmitted” but not satisfying “the minimum time gap (T_3) between the PSFCH occasion and a slot of the earliest reserved PSSCH resource indicated by the corresponding SCI after the PSFCH occasion”,
o the PSFCH occasion cannot be used by UE-A for a conflict indication for reserved PSSCH resource other than the earliest reserved PSSCH resource indicated by the corresponding SCI after the PSFCH occasion
Agreement
(Pre)configuration of parameters related to n+T_1 and n+T_2 for determining the set of preferred resources in inter-UE coordination information triggered by a condition other than explicit request reception is not supported.
· Note that T_2 is no smaller than T_2,min and 0 <= T_1 <= Tproc,1 as specified in TS 38.214 section 8.1.4.
R1-2202258 Feature lead summary #5 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
Decision: As per email decision posted on Mar 3rd,
Agreement
For inter-UE coordination information transmission, only when the cast type of inter-UE coordination information is unicast regardless of whether or not it is multiplexed with other data, a SCI format 2-C can be used in addition to MAC CE.
R1-2202665 Feature lead summary #6 for AI 8.11.1.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From Mar 3rd GTW session
Agreement
Agreement
Agreement
For sensing window for determining the set of resources in Scheme 1,
Agreement
For the case when it is not possible that the number of candidate single-slot resources after applying the received non-preferred resource set as per the existing agreement meets the requirement of X*M_total in step 7),
· It is up to UE-B’s implementation whether to take the received non-preferred resource set in its resource selection after step 6) to meet this requirement
Final summary in R1-2202666.
R1-2201113 Other aspects on SL enhancements vivo
R1-2201337 Discussion on the status of Rel-17 Sidelink enhancements CATT, GOHIGH
R1-2201532 On gNB-designated resources for inter-UE coordination and sensing in SL DRX InterDigital, Inc.
R1-2202033 Discussion on Sidelink Enhancement Samsung
R1-2202264 Additional considerations on resource allocation for power saving and inter-UE coordination Ericsson
R1-2202378 Consideration on UE-A for inter-UE coordination ZTE, Sanechips
R1-2202444 Physical layer impacts of sidelink DRX Huawei, HiSilicon
R1-2205568 Session notes for 8.11 (Maintenance on NR Sidelink enhancement) Ad-Hoc Chair (Huawei)
R1-2205117 Moderator Summary for preparation phase on maintenance on NR sidelink enhancement Moderator (LG Electronics)
R1-2204900 Addition on Rel-17 inter-UE coordination function for TS38.300 Huawei, HiSilicon
[109-e-R17-Sidelink-01] – Zichao (vivo)
Email discussion on LS (R1-2203042) on inter-UE coordination mechanism, including issues 2-11 and 2-10 as summarized in section 4 of R1-2205117, until May 12
R1-2205290 Moderator Summary #1 of email discussion [109-e-R17-Sidelink-01] Moderator (vivo)
Decision: As per email decision posted on May 16th, the following is agreed as response to RAN2
Conclusion
RAN1 thanks RAN2 for the LS asking the definitions of higher layer parameters priorityScheme1CoordInfoExplicit, priorityScheme1Request, and priorityScheme1CoordInfoCondition.
RAN1 introduced these higher layer parameters (priorityScheme1CoordInfoExplicit, priorityScheme1Request, and priorityScheme1CoordInfoCondition) for various purposes relating to priority, including the following:
In detail, the UE follows the behaviour in the RAN1 agreements below:
|
Agreement · For inter-UE coordination information triggered by an explicit request in Scheme 1, the priority value of the inter-UE coordination information is (pre)configured priority value if it is provided by (pre)configuration. Otherwise, the priority value is the same as indicated by UE-B’s explicit request. o For the case when inter-UE coordination information is transmitted together with other data, the priority value of the multiplexed sidelink transmission is determined by the smallest priority value between the inter-UE coordination information and data Agreement · For inter-UE coordination information triggered by an explicit request in Scheme 1, the priority value of explicit request is (pre)configured priority value if it is provided by (pre)configuration. Otherwise, the priority value is the same as that of a TB to be transmitted by UE-B. o For the case when the explicit request is transmitted together with other data, the priority value of the multiplexed sidelink transmission is determined by the smallest priority value between the explicit request and data Agreement · For inter-UE coordination information triggered by a condition other than explicit request reception in Scheme 1, the priority value of the inter-UE coordination information is (pre)configured priority value if it is provided by (pre)configuration. o FFS: Otherwise, the priority value is determined by UE-A’s implementation. o For the case when inter-UE coordination information is transmitted together with other data, the priority value of the multiplexed sidelink transmission is determined by the smallest priority value between the inter-UE coordination information and data |
Note: It is up to RAN2 to decide whether to fix the priorities of IUC MAC CE and IUC request MAC CE to ‘1’, as well as whether/how to update the related RAN2 specifications.
R1-2205333 Draft reply LS on the inter-UE coordination mechanism Moderator (vivo)
Decision: As per email decision posted on May 16th, the draft LS is endorsed assuming the addition of R1-2203042 (R2-2203695) in response to field. Final LS is approved in R1-2205400.
Final summary in R1-2205332 Moderator Summary #2 of email discussion [109-e-R17-Sidelink-01] Moderator (vivo)
R1-2203059 Remaining aspects of Power consumption reduction for sidelink resource allocation FUTUREWEI
R1-2203092 Remaining issues on sidelink resource allocation to reduce power consumption Huawei, HiSilicon
R1-2203312 Remaining issues on sidelink resource allocation for power saving Spreadtrum Communications
R1-2203360 Maintenance on resource allocation for power saving ZTE, Sanechips
R1-2203424 Maintenance on resource allocation for power saving CATT, GOHIGH
R1-2203524 Remaining issues on resource allocation for power saving vivo
R1-2203701 Remaining issues on sidelink resource allocation for power saving Lenovo
R1-2203710 Discussion on resource allocation for power saving LG Electronics
R1-2203774 Discussion on remaining issues on resource allocation for power saving xiaomi
R1-2203872 Maintenance on Resource Allocation for Power Saving Samsung
R1-2203971 Remaining essential issues on power saving RA OPPO
R1-2204046 Remaining issues on resource allocation for power saving InterDigital, Inc.
R1-2204173 Remaining issues on resource allocation for power saving Sharp
R1-2204214 On sidelink resource allocation for power saving Apple
R1-2204280 Remaining issues on resource allocation for power saving CMCC
R1-2204352 Maintenance of sidelink resource allocation for power saving NTT DOCOMO, INC.
R1-2204719 On resource allocation for sidelink power saving MediaTek Inc.
R1-2204736 Remaining open issues on resource allocation procedures for power saving Ericsson
[109-e-R17-Sidelink-02] – Kevin (OPPO)
Email discussion on resource allocation for power saving, for issues 1-1, 1-3, 1-4, 1-5, 1-9 (including 1-28, 1-29), 1-32, 1-24, 1-25, 1-45, 1-46, 1-47 and 1-48, as summarized in section 4 of R1-2205117
- 1st check point: May 13 (any RRC impact by May 12)
- Final check point: May 18
R1-2205061 FL summary #1 for AI 8.11.1 – Maintenance on NR sidelink resource allocation for power saving Moderator (OPPO)
R1-2205062 FL summary #2 for AI 8.11.1 – Maintenance on NR sidelink resource allocation for power saving Moderator (OPPO)
R1-2205063 FL summary #3 for AI 8.11.1 – Maintenance on NR sidelink resource allocation for power saving Moderator (OPPO)
Decision: As per email decision posted on May 13th,
Agreement
· The text proposals (for TS38.214 v17.1.0, clause 8.1.4) in sections 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5 and 2.1.6 of R1-2205063 are endorsed. The “reason for change”, “summary of change” and “consequences if not approved” for these TPs is provided in section 2.1 of R1-2205063 for information to the specification editor.
R1-2205408 FL summary #4 for AI 8.11.1 – Maintenance on NR sidelink resource allocation for power saving Moderator (OPPO)
From May 16th GTW session
Agreement
· The following TP correction for TS38.214 is to be implemented to resolve issue #1-32.
|
<Unchanged parts omitted> When the UE performs contiguous partial
sensing with periodic reservation for another TB (sl-MultiReserveResource)
disabled and if |
Agreement
· The following TP correction for TS38.214 is to be implemented to resolve the issue on selection of Y’ candidate slots should be based on corresponding PBPS and/or CPS results (if available).
|
- |
Agreement
· The following TP correction is to be made in TS38.214 Section 8.1.4.
“When periodic
reservation for another TB (sl-MultiReserveResource) is enabled for
the resource pool, the resource pool is (pre-)configured with allowedResourceSelectionConfig including partial
sensing, and partial sensing is (pre-) configured
in the UE by higher layer, the UE performs periodic-based partial
sensing.
R1-2205409 FL summary #5 for AI 8.11.1 – Maintenance on NR sidelink resource allocation for power saving Moderator (OPPO)
From May 19th GTW session
Proposal 1-1 (V):
In Step 6 c) of TS38.214 Section 8.1.4, when UE is configured with partial sensing by its higher layer,
When additionalPeriodicSensingOccasion is (pre-)configured and if 
, 
and the sensing occasion 
belongs to 
for a given periodicity 
,
o 
+1
otherwise,
o reuse the legacy Q procedure
Chair’s observation: there is no consensus whether a previous agreement is implemented in the current version of the specifications.
Agreement
The following TP correction is to be made in TS38.214 Section 8.1.4.
“When periodic reservation for another TB (sl-MultiReserveResource) is enabled for the resource pool, the resource pool is (pre-)configured with allowedResourceSelectionConfig including partial sensing, and partial sensing is (pre-) configured in the UE by higher layer, the UE performs periodic-based partial sensing, unless other conditions state otherwise in the specification.”
Final summary in R1-2205064.
R1-2203060 Remaining aspects for inter-UE coordination FUTUREWEI
R1-2203093 Remaining issues on Inter-UE coordination in sidelink resource allocation Huawei, HiSilicon
R1-2203126 Inter-UE coordination for Mode 2 enhancements Nokia, Nokia Shanghai Bell
R1-2203313 Remaining issues on inter-UE coordination in sidelink resource allocation Spreadtrum Communications
R1-2203361 Maintenance on inter-UE coordination ZTE, Sanechips
R1-2203425 Maintenance on inter-UE coordination for mode 2 enhancements CATT, GOHIGH
R1-2203525 Remaining issues on inter-UE coordination vivo
R1-2203641 Remaining issues on Rel.17 inter-UE coordination Mitsubishi Electric RCE
R1-2203676 Maintenance on inter-UE coordination for mode 2 enhancements NEC
R1-2203702 Remaining issues on inter-UE coordination for Mode 2 enhancements Lenovo
R1-2205096 Discussion on inter-UE coordination for Mode 2 enhancements LG Electronics (rev of R1-2203711)
R1-2203748 Inter-UE coordination for Mode 2 enhancements Panasonic Holdings Corporation
R1-2203775 Remaining details on inter-UE coordination xiaomi
R1-2203873 Maintenance on Inter-UE Coordination for Mode2 Enhancements Samsung
R1-2203972 Remaining essential issues on inter-UE coordination OPPO
R1-2204047 On remaining open issues for Mode 2 Inter-UE Coordination InterDigital, Inc.
R1-2204174 Remaining issues on Inter-UE coordination for Mode 2 enhancements Sharp
R1-2204215 On inter-UE coordination Apple
R1-2204281 Remaining issues on inter-UE coordination for Mode 2 enhancements CMCC
R1-2204353 Maintenance of sidelink resource allocation for reliability and latency NTT DOCOMO, INC.
R1-2204649 Remaining issues on inter-UE coordination for Mode 2 enhancements ETRI
R1-2204727 Discussion on Mode 2 enhancements MediaTek Inc.
R1-2204737 Remaining open issues on mode 2 enhancements for inter-UE coordination and related text proposals Ericsson
R1-2204993 Remaining Issues in Mode 2 Inter-UE Coordination Qualcomm Incorporated
[109-e-R17-Sidelink-03] – Seungmin (LGE)
Email discussion on inter-UE coordination for mode 2 enhancements, for scheme 1 issues 2-1, 2-2/2-5/2-7, 2-3, 2-8, and for scheme 2 issues 2-25, 2-29 and issue of R1-2204898, as summarized in section 4 of R1-2205117
- 1st check point: May 13 (any RRC impact by May 12)
- Final check point: May 18
R1-2203716 Feature lead summary #1 for AI 8.11.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
R1-2203717 Feature lead summary #2 for AI 8.11.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
Decision: As per email decision posted on May 13th,
Agreement
· TP#1 (for TS38.213 v17.1.0, clause 16.4) in section 8.1 of R1-2203717 is endorsed.
· TP#2 (for TS38.213 v17.1.0, clause 16.2.3) in section 8.2 of R1-2203717 is endorsed.
R1-2205317 Feature lead summary #3 for AI 8.11.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
R1-2205318 Feature lead summary #4 for AI 8.11.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From May 18th GTW session
Agreement
· When UE-B receives both a single preferred resource set and a single non-preferred resource set from the same UE-A or different UE-As, when UE-B has own sensing results
o No RAN1 specification change to TS 38.214 is deemed necessary on how it uses the non-preferred resource set in its resource (re)selection
o It is up to UE-B implementation to use the preferred resource set in its resource (re)selection for transmissions to the UE A providing the preferred resource set
Agreement
Remove the sentence below in Section 8.1.5A of TS 38.214
|
[When a preferred resource set is indicated by an SCI format 2-C, if the transmission of the set was triggered by an explicit request, the value of the resource reservation interval P_(rsvp,m) is set to 0.] |
R1-2205494 Feature lead summary #5 for AI 8.11.2 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
From May 19th GTW session
Agreement
· X1, X2, and X3 are determined by UE-A’s implementation under the constraints defined in the specification (e.g., SL-LatencyBoundIUC-Report-r17, requirement of T_2min)
o UE-B can choose to not use any resource from the preferred/non-preferred resource set in its resource (re-)selection if that resource is earlier than (Tproc,0+Tproc,1+Tproc,2) after the resource of inter-UE coordination information transmission
§ For Tproc,2,
· When only MAC CE is used for inter-UE coordination information transmission, it is equal to (Tproc,0+Tproc,1)
· When MAC CE and SCI format 2-C are both used for inter-UE coordination information transmission, it is equal to Tproc,0
o Note: this is assuming that SCI format 2-C is received
o Whether or not to make the time gap from the resource of inter-UE coordination information transmission to preferred/non-preferred resource in the inter-UE coordination information larger than (Tproc,0+Tproc,1+Tproc,2) is up to UE-A implementation
Decision: As per email decision posted on May 21st,
Agreement
Adopt the following text proposal to TS 38.214 v17.1.0:
· Reason for change:
o RAN1 discussed how to alleviate an ambiguity of UE-B’s behavior in terms of handling the field of resource reservation period in the inter-UE coordination information considering that there is no special mechanism that makes UE-B distinguishable whether the inter-UE coordination information is triggered by an explicit request or triggered by a condition, and agreed that this field is always valid.
· Summary of change:
o Delete the sentence of “[When a preferred resource set is indicated by an SCI format 2-C, if the transmission of the set was triggered by an explicit request, the value of the resource reservation interval P_(rsvp,m) is set to 0.]” in Section 8.1.5A of TS 38.214.
· Consequences if not approved:
o The specification is not clear regarding UE-B’s behavior on handling the field of resource reservation period in the inter-UE coordination information.
|
----------------------- Start of text proposal to TS 38.214 v17.1.0 ----------- 8.1.5A UE procedure for determining slots and resource blocks indicated by a preferred or non-preferred resource set The set of slots and resource blocks indicated by a set of preferred or non-preferred resource(s) is determined as described below.
The
set of preferred or non-preferred resources
The
reference slot - the value of sl-MaxNumPerReserve is fixed to 3. -
"slot where SCI format 1-A was received" is replaced by slot
indicated as the first resource location of a -
the first resource location of each -
the starting sub-channel The
starting sub-channel
If
the set is indicated by an SCI format 2-C, the number of tuples is
A
UE forms the union of the subsets indicated by each tuple
------------------------ End of Text proposal to TS 38.214 v17.1.0 ---------- |
Final summary in R1-2205547.
R1-2203362 Additional consideration on inter-UE coordination ZTE, Sanechips
R1-2203426 Discussion on the status of Rel-17 Sidelink enhancements CATT, GOHIGH
R1-2204048 Additional discussions on conflict indication timeline InterDigital, Inc.
R1-2204738 Remaining critical issues for random resource selection and the relationship between power saving and inter-UE coordination mechanism Ericsson
R1-2204898 Other text proposals for specifications Huawei, HiSilicon
R1-2208141 Session notes for 8.11 (Maintenance on NR Sidelink enhancement) Ad-Hoc Chair (Huawei)
[110-R17-SL] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Seungmin (LG Electronics)
R1-2205742 Correction for inter-UE coordination Scheme 2 determination of UE-B FUTUREWEI
R1-2205766 Remaining issues on maintenance of Rel-17 sidelink enhancements Huawei, HiSilicon
R1-2205848 Discussion on maintenance on NR sidelink enhancement LG Electronics
R1-2205977 Remaining issues on NR Sidelink enhancement Spreadtrum Communications
R1-2206096 Maintenance on NR SL enhancement ZTE, Sanechips
R1-2206283 Remaining essential issues in R17 NR sidelink enhancement OPPO
R1-2206360 Maintenance on NR sidelink enhancement CATT, GOHIGH
R1-2206447 Remaining issues on resource allocation for sidelink enhancement Lenovo
R1-2206468 Editorial correction for inter-UE coordination NEC
R1-2206562 Discussion on LS Related to RRC Parameters for IUC Scheme 1 and Default CBR Configuration Intel Corporation
R1-2206563 Discussion on LS on IUC with Non-Preferred Resource Set Intel Corporation
R1-2206763 Maintenance on NR Sidelink enhancement vivo
R1-2206804 Maintenance on NR sidelink enhancement Samsung
R1-2206890 Maintenance on NR Sidelink enhancement CMCC
R1-2206936 Remaining issues on NR sidelink enhancement Sharp
R1-2207146 Remaining issues on R17 SL Enhancement InterDigital, Inc.
R1-2207206 Remaining issues in Sidelink Qualcomm Incorporated
R1-2207313 On Maintenance of NR Sidelink Enhancement Apple
R1-2207386 Maintenance of sidelink enhancement NTT DOCOMO, INC.
R1-2207483 Maintenance on Inter-UE coordination ASUSTeK
R1-2207563 Critical corrections and remaining issues on NR SL enhancement Ericsson
From AI 5
R1-2205727 LS on RRC parameters for IUC Scheme 1 and default CBR configuration RAN2, Huawei
R1-2208024 Moderator summary for reply LS to R1-2205727 Moderator (Huawei)
R1-2208025 Draft reply LS to RAN2 on RRC parameters for IUC Scheme 1 and default CBR configuration Huawei, HiSilicon
Agreement
The draft LS reply in R1-2208025 is endorsed by
· replacing the response to Q2 by: RAN1’s reply: TS 38.321 already captures this condition, i.e., UE-A is the intended receiver of UE-B. In addition to what is specified in TS38.321, TS 38.214 Clause 8.1.4A captures this condition as “the UE is a destination UE of the TB for whose transmission the preferred resource set is being determined”.
· Revising the response to Q1 to: RAN1’s reply: IUC request is not always piggybacked with SL data. Whether UE-B piggybacks the IUC Request with SL data transmission is as per TS 38.321 and the below RAN1 agreements. The resource set provided by UE-A based on the IUC request will be used to determine UE-B’s transmission resources to transmit the data.
Final LS is approved in R1-2208090. Final summary in R1-2208091.
From AI 5
R1-2205728 LS on IUC with non-preferred resource set RAN2, Apple
R1-2208080 Moderator Summary of Email Discussion on Reply LS in R1-2205728 Moderator (Apple)
R1-2208222 [Draft] Reply LS to RAN2 on IUC with Non-preferred Resource Set Apple
No consensus for a reply LS.
R1-2205735 LS on power-saving resource allocation with absent sl-AllowedResourceSelectionConfig RAN2, vivo
R1-2207952 Moderator Summary of discussion for LS reply to R1-2205735 Moderator (vivo)
R1-2207953 Draft reply LS on power-saving resource allocation with absent sl-AllowedResourceSelectionConfig Moderator (vivo)
Decision: The draft LS in R1-2207953 is endorsed. Final LS is approved in R1-2208097.
From AI 5
R1-2207813 LS on missing RRC parameter in IUC Scheme 2 RAN2, Apple
R1-2208078 Moderator Summary of Email Discussion on Reply LS to R1-2207813 Moderator (Apple)
R1-2208079 [Draft] Reply LS to RAN2 on Missing RRC Parameter in IUC Scheme 2 Moderator (Apple)
Agreement
·
The draft LS in R1-2208079 is endorsed with the addition of “RAN1 would additionally like to
tell RAN2 that this parameter is expected to the be resource
pool specific.”.
Final LS is approved in R1-2208123. Final summary in R1-2208159.
R1-2207766 Feature lead summary #1 for AI 8.11 Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
Agreement
· Reason for change:
o The RAN1 agreement related to UE-B's behaviour of determining a resource used for its resource (re-)selection among the non-preferred resource set received from UE-A is not captured in the specification.
· Summary of change:
o The relevant UE-B's behaviour is described in Section 8.1.4C of TS 38.214.
· Consequences if not approved:
o The specification text is unclear as to which resource UE-B uses for its resource (re-)selection among the non-preferred resource set received from UE-A
|
--------------------------- Start of text proposal to TS 38.214 v17.2.0 --------------------------- 8.1.4C UE procedure for using a received non-preferred resource set
A UE configured with the higher layer parameter interUECoordinationScheme1 uses a received non-preferred resource set as follows when performing resource (re-)selection:
- the UE excludes in Step 6b) of clause 8.1.4 resource(s) overlapping with the non-preferred resource set.
Note: If it
is not possible to meet the requirement that the number of
candidate single-slot resources remaining in the set
Note: The UE is not required to use any resource from the non-preferred resource set in its resource (re-)selection if that resource is earlier than (Tproc,0+Tproc,1+Tproc,2) after the resource of inter-UE coordination information transmission, where Tproc,2 is equal to (Tproc,0+Tproc,1) when only MAC CE is used for inter-UE coordination information transmission, or Tproc,2 is equal to Tproc,0 when MAC CE and SCI format 2-C are both used for inter-UE coordination information transmission. Note: the case when Tproc,2 is equal to Tproc,0 is assuming that SCI format 2-C is received.
--------------------------- End of Text proposal to TS 38.214 v17.2.0 --------------------------- |
Agreement
· Reason for change
o Regarding the cast type for SCI format 2-C, the following agreement was reached. However, it seems that there is no corresponding text in the specification.
|
Agreement For inter-UE coordination information transmission, only when the cast type of inter-UE coordination information is unicast regardless of whether or not it is multiplexed with other data, a SCI format 2-C can be used in addition to MAC CE |
· Summary of change
o Clarify that SCI format 2-C can be used only for unicast.
· Consequences if not approved
o The cast type for which SCI format 2-C was agreed is not explicitly reflected in the specification.
|
--------------------------- Start of text proposal to TS 38.212 v17.2.0 --------------------------- 8.4.1.3 SCI format 2-C SCI format 2-C is used for the decoding of PSSCH, and providing inter-UE coordination information or requesting inter-UE coordination information. SCI format 2-C can be used only for unicast. The following information is transmitted by means of the SCI format 2-C: <Unchanged parts omitted> --------------------------- End of Text proposal to TS 38.212 v17.2.0 --------------------------- |
Final summary in R1-2207767.
R1-2207785 FL summary #1 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
Agreement
The editorial corrections for issues #28, 29, 30 in section 3.6 of R1-2207785 are provided to the 38.214 specification editor.
R1-2207786 FL summary #2 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
Agreement
The following TP correction is to be made in TS38.214 Section 8.1.4.
“When a UE is triggered by higher layer to report resources
for resource (re-)selection in a mode 2 Tx pool, the resource pool is
(pre-)configured with allowedResourceSelectionConfig including partial sensing,
and partial sensing is configured by higher layer, the UE may performs contiguous partial sensing,
unless stated otherwise in the specification.”
R1-2207787 FL summary #3 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
Final summary in R1-2207788.
R1-2210686 Session notes for 8.11 (Maintenance on NR Sidelink enhancement) Ad-Hoc Chair (Huawei)
R1-2209951 Draft CR on Resource Pool Index in DCI 3_0 for Discovery Qualcomm Incorporated
R1-2210129 [Draft] Modification on Resource Pool index for DCI Format 3_0 Ericsson
[110bis-e-R17-SL-01] – Seungmin (LGE)
Email discussion to determine maintenance issues to be handled in RAN1#110bis-e by October 12
- Additional email discussions will be set up once the maintenance issues for RAN1#110bis-e are determined
R1-2210333 Moderator summary for AI 8.11: Maintenance on NR sidelink enhancement Moderator (LG Electronics)
Decision: As per email decision posted on Oct 12th,
Conclusion of [110bis-e-R17-SL-01]:
For Rel-17 NR sidelink enhancement maintenance on resource allocation for power saving, based on the issues described in R1-2210333:
· Discuss issues 1-6, 1-7, 1-9
· Discuss the following editorial issues for providing to spec editors: issues 1-15, 1-16, 1-17
For Rel-17 NR sidelink enhancement maintenance inter-UE coordination for mode 2 enhancements and other issues, based on the issues described in R1-2210333:
· Discuss issues 2-15, 2-4, 2-10, 3-1, 3-3
· Discuss the following editorial issues for providing to spec editors: issues 2-2, 2-7, 2-8, 2-9, 2-17, 2-11, 2-12, 2-13
The following issues in R1-2210333 are postponed and will be treated at RAN1#111: issues 1-2, 1-10, 1-12, 1-13, 2-1.
The following issues in R1-2210333 will not be treated at RAN1#111: issues 1-3, 1-4, 1-5, 1-8, 2-3, 2-5, 2-20, 2-21, 2-22.
/To be handled using NWM – please use 110bis-e-NWM-R17-SL-02 as the document name
[110bis-e-R17-SL-02] – Chunxuan (Apple)
Email discussion on incoming RAN2 LS in R1-2205728 (R2-2206314) on IUC and non-preferred resources by October 14
R1-2210481 Moderator summary for reply LS to R1-2205728 Moderator (Apple)
R1-2210482 Draft reply LS to RAN2 on IUC with non-preferred resource set Apple
Decision: As per email decision posted on Oct 15th, the draft LS reply in R1-2210482 is endorsed. Final LS is approved in R1-2210582.
R1-2208386 Discussion on resolving ambiguous text in 38.214 FUTUREWEI
R1-2208610 Corrections for partial sensing resource selection vivo
R1-2208816 Draft CR on Q formula in step 6c for periodic-based partial sensing OPPO
R1-2208817 Draft CR on CPS sensing window OPPO
R1-2208818 Draft CR on the description of candidate slots for partial sensing OPPO
R1-2208819 Draft CR on starting slot and pre-condition in re-evaluation and pre-emption checking for partial sensing OPPO
R1-2208919 Correction on the operations of partial sensing CATT, GOHIGH
R1-2208922 Discussion on remaining issues for R17 eSL power saving RA maintenance CATT, GOHIGH
R1-2209309 Corrections on the selection of Y or Y’ candidate slots for partial sensing CMCC
R1-2209562 Correction on Q formula for the second most recent periodic sensing occasion Apple
R1-2209563 Correction on CPS monitoring length during sidelink DRX inactive time Apple
R1-2209676 Clarification on pre-emption and re-evaluation for periodic transmission in partial sensing Sharp
R1-2209677 Clarification on monitoring slots for pre-emption check due to half-duplex constraint in partial sensing Sharp
R1-2209678 Correction on candidate slots selection for partial sensing Sharp
R1-2209680 Clarification on Preserve for periodic based partial sensing Sharp
R1-2209681 Clarification on candidate slots for aperiodic transmission in partial sensing Sharp
R1-2209683 Remaining issues on NR sidelink enhancement Sharp
R1-2209827 Correction on Q formula in step 6 of sensing and resource exclusion procedure in TS 38.214 Huawei, HiSilicon
R1-2209828 Correction on description of random resource selection in TS 38.214 Huawei, HiSilicon
R1-2209874 Draft CR on half-duplex consideration for SL re-evaluation/pre-emption check NTT DOCOMO, INC.
R1-2209875 Draft CR on insufficient candidate resources for SL re-evaluation/pre-emption check NTT DOCOMO, INC.
R1-2209876 Draft CR on slot n+T3 excluded from SL re-evaluation/pre-emption check NTT DOCOMO, INC.
R1-2209877 Draft CR on Y/Y’ candidate slots for SL partial sensing NTT DOCOMO, INC.
R1-2210125 [Draft] Consideration of associated processing times for contiguous partial sensing Ericsson
R1-2210126 [Draft] Correction to allowed resource selection mechanisms in a resource pool in mode 2 Ericsson
R1-2210127 [Draft] Correction to contiguous partial sensing window Ericsson
R1-2210154 Draft CR on corrections for the description of candidate slots in TS38.214 Lenovo
[110bis-e-R17-Sidelink-03] – Kevin (OPPO)
Email discussion for maintenance on resource allocation for power saving for the following issues in R1-2210333
- Issues 1-6, 1-7, 1-9
- Editorial issues for providing to spec editors: issues 1-15, 1-16, 1-17
- Check points: October 14, October 19
R1-2210285 FL summary #1 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
Agreement
Adopt the following TP for TS 38.214
------------------------------------------------ Start of Text Proposal for TS 38.214 ------------------------------------------------
8.1.4 UE procedure for determining the subset of resources to be reported to higher layers in PSSCH resource selection in sidelink resource allocation mode 2
<Unchanged parts omitted>
- Optionally,
minimum number of Y slots as 
(sl-MinNumCandidateSlotsPeriodic),
which indicates the minimum number of Y slots that are included in the
candidate resources corresponding to periodic-based partial sensing and contiguous partial sensing for
resource (re)selection triggered by periodic transmission (
)operation.
- Optionally,
minimum number of 
slots
as 
(sl-MinNumCandidateSlotsAperiodic), which indicates the minimum number of slots
that are included in the candidate resources
corresponding to periodic-based partial sensing and/or contiguous
partial sensing operationresults (if available) for
resource (re)selection triggered by aperiodic transmission (
).
--------------------------------------------------------End of Text Proposal ------------------------------------------------------------
R1-2210495 Correction on the description for the minimum number of Y and Y’ candidate slots in sidelink partial sensing Moderator (OPPO)
Decision: As per email decision posted on Oct 14th, the draft CR to issue 1-6 is endorsed in principle. Agreed as (TS38.214, Rel-17, CR#0348, Cat F) in
R1-2210555 Correction on the description for the minimum number of Y and Y’ candidate slots in sidelink partial sensing Moderator (OPPO), Samsung, Lenovo, Ericsson, CATT, GOHIGH, ZTE, Sanechips, Huawei, HiSilicon, NTT DOCOMO, vivo
Agreement
Adopt the TP below for TS38.214
------------------------------------------------ Start of Text Proposal for TS 38.214 ------------------------------------------------
8.1.4 UE procedure for determining the subset of resources to be reported to higher layers in PSSCH resource selection in sidelink resource allocation mode 2
<Unchanged parts omitted>
1) A
candidate single-slot resource for transmission 
is defined
as a set of 
contiguous
sub-channels with sub-channel x+j in slot 
where 
. The UE
shall assume that any set of contiguous
sub-channels included in the corresponding resource pool within the time
interval 
correspond
to one candidate single-slot resource for
UE performing full sensing, in a set of Y candidate slots within the
time interval 
for UE
performing periodic-based partial sensing correspond
to one candidate single-slot resource for UE performing
periodic-based partial sensing together with contiguous
partial sensing and resource (re)selection
triggered by periodic transmission (
),
or in a set of Y' candidate slots within the time interval for UE
performing contiguous partial sensing if Prsvp_TX=0,
correspond to one candidate single-slot resource for UE performing at
least contiguous partial sensing and resource
(re)selection triggered by aperiodic
transmission (), where
·
- selection of 
is up to UE
implementation under 
, where is defined
in slots in Table 8.1.4-2 where 
is the SCS
configuration of the SL BWP;
·
- if 
is shorter
than the remaining packet delay budget (in slots) then 
is up to UE
implementation subject to 
remaining
packet delay
budget
(in slots); otherwise is set to the
remaining packet delay budget (in slots).
·
- 
is selected
by UE where 
.
·
- is selected
by UE where 
. When the UE
performs at least contiguous partial sensing
and if , the UE
selects a set of candidate
slots with corresponding PBPS and/or CPS results (if available). If the number of candidate
single-slot resources is smaller than 
, it is up to
UE implementation to include other candidate slots.
·
The total number of candidate single-slot
resources is denoted by 
.
--------------------------------------------------------End of Text Proposal ------------------------------------------------------------
R1-2210496 Correction on the selection of Y and Y’ candidate slots in sidelink partial sensing Moderator (OPPO)
Decision: As per email decision posted on Oct 14th, the draft CR to issue 1-7 is endorsed in principle. Agreed as (TS38.214, Rel-17, CR#0349, Cat F) in
R1-2210556 Correction on the selection of Y and Y’ candidate slots in sidelink partial sensing Moderator (OPPO), Samsung, Lenovo, Ericsson, CATT, GOHIGH, ZTE, Sanechips, Huawei, HiSilicon, NTT DOCOMO, vivo
R1-2210286 FL summary #2 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
R1-2210287 FL summary #3 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
Decision: As per email decision posted on Oct 15th,
For alignment TS38.214 CR:
· Text proposal 1-15/16/17 (II) in section 3.1.2 of R1-2210287 is endorsed for the editorial corrections.
Agreement
· Text Proposal 1-9 (II) in Section 2.3.2 of R1-2210287 is endorsed.
Corresponding draft CR in:
R1-2210497 Corrections on CPS operation in sidelink partial sensing Moderator (OPPO)
Decision: As per email decision posted on Oct 19th, the draft CR is endorsed. Final CR (TS38.214, Rel-17, CR#0364, Cat F) is agreed in:
R1-2210710 Corrections on CPS operation in sidelink partial sensing Moderator (OPPO), vivo, Samsung, Lenovo, Intel, Huawei, HiSilicon, ZTE, Sanechips, CATT, GOHIGH, CMCC
Final summary in R1-2210288.
R1-2208385 Discussion on correction for inter-UE coordination Scheme 2 determination of UE-B FUTUREWEI
R1-2208386 Discussion on resolving ambiguous text in 38.214 FUTUREWEI
R1-2208609 Clarification on missing field descriptions of SCI 2-C vivo
R1-2208611 Clarification for inter-UE coordination scheme-2 vivo
R1-2208612 Clarification on IUC related transmission based on latency bound vivo
R1-2208613 Corrections for missing functions of SCI 2-c vivo
R1-2208716 Field naming alignment for SCI format 2-C in TS38.214 ZTE, Sanechips
R1-2208717 Clarification on Condition 2-A-1 for scheme 2 ZTE, Sanechips
R1-2208718 Clarification on Condition 2-A-2 for scheme 2 ZTE, Sanechips
R1-2208719 Corrections on misalignment for RRC parameters in TS 38.214 ZTE, Sanechips
R1-2208720 Corrections on misalignment for RRC parameters in TS 38.213 ZTE, Sanechips
R1-2208721 Corrections on misalignment for RRC parameters in TS 38.212 ZTE, Sanechips
R1-2208920 Correction on resource exclusion behavior with non-preferred resource set CATT, GOHIGH
R1-2208921 Discussion on resource exclusion behavior with non-preferred resource set CATT, GOHIGH
R1-2209135 Draft CR on RRC parameter name and value misalignment in TS 38.213 NEC
R1-2209136 Draft CR on RRC parameter name and value misalignment in TS 38.214 NEC
R1-2209564 Correction on determining UE-B among UEs scheduling conflicting TBs Apple
R1-2209565 Correction on priority value of PSFCH transmission with conflict information for condition 2-A-2 Apple
R1-2209682 Correction on handling of conflict information receiver flag Sharp
R1-2209683 Remaining issues on NR sidelink enhancement Sharp
R1-2209798 Draft CR on Inter-UE coordination in TS 38.212 ASUSTeK
R1-2209799 Draft CR on Inter-UE coordination in TS 38.213 ASUSTeK
R1-2209801 Draft CR on Inter-UE coordination in TS 38.214 ASUSTeK
R1-2209830 Correction on description of valid PSFCH occasion for scheme 2 in TS 38.213 Huawei, HiSilicon
R1-2209873 Draft CR on condition to be UE-A for SL IUC scheme 2 NTT DOCOMO, INC.
R1-2209878 Editorial corrections for SL IUC (38.212) NTT DOCOMO, INC.
R1-2209879 Editorial corrections for SL IUC (38.213) NTT DOCOMO, INC.
R1-2209880 Editorial corrections for SL IUC (38.214) NTT DOCOMO, INC.
R1-2209881 Discussion on RAN2-related topics for SL maintenance NTT DOCOMO, INC.
R1-2209950 Draft CR on Non-preferred Resources Qualcomm Incorporated
R1-2209952 Discussion on Corrections to NR Sidelink Qualcomm Incorporated
R1-2210060 Draft CR on the Notes in section 8.1.4C of 38.214 Nokia, Nokia Shanghai Bell
R1-2210124 [Draft] Clarification on valid PSFCH occassions for resource conflict information Ericsson
R1-2210128 [Draft] Correction to priority definition for Tx and Rx of PSFCH with conflict information Ericsson
R1-2210184 Corrections for SL Inter-UE coordination Nokia, Nokia Shanghai Bell
R1-2210185 Corrections for SL Inter-UE coordination Nokia, Nokia Shanghai Bell
R1-2210203 Correction on UE-A is the destination UE of a TB transmitted by UE-B in TS 38.214 Huawei, HiSilicon
R1-2210204 Correction on RRC parameter names and values used for SCI format 1-A and 2-C in TS 38.212 Huawei, HiSilicon
R1-2208614 Discussion on PDCCH repetition for sidelink vivo
R1-2208615 Clarification on PDCCH repetition for sidelink-38.213 vivo
R1-2208616 Clarification on PDCCH repetition for sidelink-38.214 vivo
R1-2209953 Draft CR on Power Control Parameters Qualcomm Incorporated
R1-2210130 [Draft] Modifications on SL open loop power control formulae Ericsson
From agenda item 7.2
R1-2209829 Correction on power control for PSCCH/PSSCH/PSFCH/S-SSB in TS 38.213 Huawei, HiSilicon
R1-2210039 Correction on SL timing Nokia, Nokia Shanghai Bell
[110bis-e-R17-Sidelink-04] – Seungmin (LGE)
Email discussion for maintenance on inter-UE coordination for mode 2 enhancements, for scheme 1 and for scheme 2, and on miscellaneous topics, for the following issues in R1-2210333
- Issues 2-15, 2-4, 2-10, 3-1, 3-3
- Editorial issues for providing to spec editors: issues 2-2, 2-7, 2-8, 2-9, 2-17, 2-11, 2-12, 2-13
- Check points: October 14, October 19
R1-2210334 Feature lead summary #1 for AI 8.11: Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
Agreement
· Adopt the TP below for TS 38.213
|
--------------------------- Start of text proposal to TS 38.213 v17.3.0 --------------------------- 16.3.0 UE procedure for transmitting PSFCH with control information < Unchanged parts are omitted > A first UE determines a second UE for providing the conflict information to in a PSFCH as follows - if the first UE is an intended receiver of the second UE for a reserved resource of a PSSCH transmission in a slot, - does
not expect to perform reception on the sidelink due to half-duplex operation
in the slot - the PSFCH occasion for resource conflict information of the second UE is valid, and - determines to transmit to the second UE the PSFCH with the conflict information. < Unchanged parts are omitted > --------------------------- End of Text proposal to TS 38.213 v17.3.0 --------------------------- |
Corresponding draft CR in:
R1-2210624 Correction on conditions for UE to be UE-B for Condition 2-A-2 of Scheme 2 Moderator (LG Electronics)
Decision: As per email decision posted on Oct 19th, draft CR is endorsed in principle. Final CR (TS38.213, Rel-17, CR#0403, Cat F) is agreed in:.
R1-2210732 Correction on conditions for UE to be UE-B for Condition 2-A-2 of Scheme 2 Moderator (LG Electronics), NTT DOCOMO, Ericsson, Samsung, ZTE, Sanechips
R1-2210335 Feature lead summary #2 for AI 8.11: Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
Decision: As per email decision posted on Oct 15th,
Agreement
· TP#1 for Issue #3-3 in section 4.1.1 of R1-2210335 is endorsed.
Corresponding draft CR in:
R1-2210623 Correction on sidelink timing Moderator (LG Electronics)
Decision: As per email decision posted on Oct 19th, draft CR is endorsed in principle. Final CR (TS38.211, Rel-17, CR#0103, Cat F) is agreed in:
R1-2210731 Correction on sidelink timing Moderator (LG Electronics), Nokia, Nokia Shanghai Bell, Ericsson, Samsung
For alignment TS38.214 CR:
· TP#1 for Issue #2-7 in section 4.2.1 of R1-2210335 is endorsed for the editorial corrections.
· TP#2 for Issue #2-8 in section 4.2.2 of R1-2210335 is endorsed for the editorial corrections.
For alignment TS38.213 CR:
· TP#3 for Issue #2-9 in section 4.2.3 of R1-2210335 is endorsed for the editorial corrections.
· TP#4 for Issue #2-17 in section 4.2.4 of R1-2210335 is endorsed for the editorial corrections.
· TP#5 for Issue #2-12 in section 4.2.5 of R1-2210335 is endorsed for the editorial corrections.
For alignment TS38.212 CR:
· TP#6 for Issue #2-13 in section 4.2.6 of R1-2210335 is endorsed for the editorial corrections.
R1-2210336 Feature lead summary #3 for AI 8.11: Inter-UE coordination for Mode 2 enhancements Moderator (LG Electronics)
Decision: As per email decision posted on Oct 19th,
Agreement
· Draft proposal 2-4 (III) for Issue #2-4 in Section 5.1.2 of R1-2210336 is endorsed in principle.
Corresponding draft CR in:
R1-2210625 Correction on the determination of the priority value of PSFCH transmission with conflict information due to Condition 2-A-2 of Scheme 2 Moderator (LG Electronics)
Decision: As per email decision posted on Oct 19th, draft CR is endorsed in principle. Final CR is agreed in R1-2210733 (TS38.213, Rel-17, CR#0404, Cat F).
Conclusion:
There is no consensus in RAN1 on the support of PDCCH repetition for search space sets configured with SL DCI format 3-0 and/or 3-1 in Rel-17.
Send LS to RAN2 to inform that this conclusion and the current RAN1 specification does not cover the case for SL DCI format 3-0 and/or 3-1 with PDCCH repetition.
R1-2210734 Draft LS on PDCCH repetition for sidelink Moderator (LG Electronics)
Decision: As per email decision posted on Oct 19th, draft LS is endorsed. Final LS is approved in R1-2210735.
For alignment TS38.214 CR:
· Draft proposal 2-2 (III) for Issue #2-2 in Section 5.2.1 of R1-2210336 is endorsed for the editorial corrections.
Agreement
· Draft proposal 2-10a (I) for Issue #2-10 in Section 2.1.3.2 of R1-2210336 is endorsed in principle.
Note the change impacts section 16.3.0 of 38.213 and shall be incorporated in the draft CR R1-2210624.
Agreement
· TP#7 for Issue #2-11 in Section 4.2.7 of R1-2210336 is endorsed for the editorial corrections.
Final summary in R1-2210621.
R1-2212840 Session notes for 8.11 (Maintenance on NR Sidelink enhancement) Ad-Hoc Chair (Huawei)
Endorsed and contents incorporated below.
[111-R17-SL] – Seungmin (LGE)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
Maintenance on resource allocation for power saving
R1-2212677 FL summary #1 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
R1-2212678 FL summary #2 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
R1-2212679 FL summary #3 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
R1-2210977 Clarification of the sensing occasions for periodic-based partial sensing vivo
R1-2211143 Correction on the operations of partial sensing CATT, GOHIGH
R1-2211853 Clarification on Preserve for periodic based partial sensing Sharp
R1-2211854 Clarification on candidate slots for aperiodic transmission in partial sensing Sharp
R1-2211962 Draft CR on insufficient candidate resources for SL re-evaluation/pre-emption check NTT DOCOMO, INC.
R1-2212218 [Draft] Consideration of associated processing times for contiguous partial sensing Ericsson
R1-2212219 [Draft] Correction to contiguous partial sensing window Ericsson
R1-2212463 Correction on description of random resource selection in TS 38.214 Huawei, HiSilicon
Note: it was decided at RAN1#110bis-e that issues 1-3, 1-4, 1-5, 1-8 in R1-2210333, relating to the Tdocs above, will not be treated at RAN1#111.
Update of Q formula in Step 6 for the 2nd most recent PSO (Issue #1-2 in R1-2212677)
R1-2210896 Correction on Q formula in step 6 of sensing and resource exclusion procedure in TS 38.214 Huawei, HiSilicon
R1-2210976 Correction on Q formula in sensing and resource exclusion procedure vivo
R1-2211442 Draft CR on Q formula in step 6c for periodic-based partial sensing OPPO
R1-2211793 Correction on Q formula for the second most recent periodic sensing occasion Apple
R1-2212202 Correction to the Q formula in Step 6 of mode 2 partial sensing procedure ZTE, Sanechips
Chair’s observation:
Regarding the agreement from RAN1#105:
· 7 companies think that agreement is not implemented in the specifications
· 5 companies think that agreement is implemented in the specifications
R1-2212955 Correction on the Q formula for periodic-based partial sensing Moderator (OPPO)
No consensus to proceed further with the proposed TP.
Step 2), correct CPS window in SL DRX inactive time (Issue #1-10 in R1-2212677)
R1-2211444 Draft CR on contiguous partial sensing window in DL DRX inactive time OPPO
R1-2211794 Correction on CPS monitoring length during sidelink DRX inactive time Apple
Re-evaluation and pre-emption checking for periodic transmission (Issue #1-12 in R1-2212677)
R1-2211443 Draft CR on starting slot and pre-condition in re-evaluation and pre-emption checking for partial sensing OPPO
R1-2211852 Clarification on monitoring slots for pre-emption check due to half-duplex constraint in partial sensing Sharp
R1-2211961 Draft CR on half-duplex consideration for SL re-evaluation/pre-emption check NTT DOCOMO, INC.
R1-2211963 Draft CR on slot n+T3 excluded from SL re-evaluation/pre-emption check NTT DOCOMO, INC.
R1-2212203 Corrections to Re-evaluation and Pre-emption Checking for Partial Sensing ZTE, Sanechips
Re-evaluation and pre-emption checking for aperiodic transmission (Issue #1-13 in R1-2212677)
R1-2211443 Draft CR on starting slot and pre-condition in re-evaluation and pre-emption checking for partial sensing OPPO
R1-2211584 Draft CR on re-evaluation and pre-emption checking for partial sensing Lenovo
R1-2211961 Draft CR on half-duplex consideration for SL re-evaluation/pre-emption check NTT DOCOMO, INC.
R1-2212203 Corrections to Re-evaluation and Pre-emption Checking for Partial Sensing ZTE, Sanechips
For issues 1-12 and 1-13
R1-2212956 Correction on the re-evaluation and pre-emption checking for periodic and aperiodic transmissions Moderator (OPPO)
Decision: The draft CR in R1-2212956 is endorsed. Final CR (TS 38.214, Rel-17, CR#0391, Cat F) is agreed in:
R1-2212992 Correction on the re-evaluation and pre-emption checking for periodic and aperiodic transmissions Moderator (OPPO), Huawei, HiSilicon, Samsung, LG Electronics, Ericsson, ZTE, Sanechips, vivo, Lenovo, NTT DOCOMO, CMCC
Final summary in R1-2212680.
Maintenance on inter-UE coordination for mode 2 enhancements, for scheme 1 and for scheme 2, and other miscellaneous issues
R1-2212597 Feature lead summary #1 for AI 8.11: Inter-UE coordination for Mode 2 enhancements and others Moderator (LG Electronics)
R1-2212598 Feature lead summary #2 for AI 8.11: Inter-UE coordination for Mode 2 enhancements and others Moderator (LG Electronics)
R1-2212599 Feature lead summary #3 for AI 8.11: Inter-UE coordination for Mode 2 enhancements and others Moderator (LG Electronics)
Issue 2-1 [Scheme 2] Further clarification on conditions for UE to be UE-B when at least one of UEs scheduling conflicting TBs does not set Conflict information receiver flag to 1
R1-2210838 Discussion on correction for inter-UE coordination Scheme 2 determination of UE-B FUTUREWEI
R1-2211795 Correction on determining UE-B among UEs scheduling conflicting TBs Apple
R1-2211960 Draft CR on condition to be UE-A for SL IUC scheme 2 NTT DOCOMO, INC.
R1-2212204 Correction on Condition 2-A-1 of IUC scheme 1 ZTE, Sanechips
Conclusion
This issue is not pursued in Rel-17.
Issue 2-6 [Scheme 1] Further clarification on IUC related transmission based on latency bound
R1-2210978 Clarification on IUC related transmission based on latency bound vivo
Issue 2-14 [Scheme 1] Modification to UE-B’s behavior of excluding the non-preferred resource set from its candidate single-slot resources
R1-2211144 Correction on resource exclusion behavior with non-preferred resource set CATT, GOHIGH
R1-2211145 Discussion on resource exclusion behavior with non-preferred resource set CATT, GOHIGH
Issue 2-19 [Scheme 2] Deletion of duplicated part on UE procedure for determining a resource conflict between TS 38.213 (Section 16.3.0) and TS 38.214 (Section 8.1.4B)
R1-2211445 Draft CR on UE procedure for determining a resource conflict OPPO
R1-2211964 Draft CR on removal of duplicated spec description on IUC scheme 2 NTT DOCOMO, INC.
Agreement
Section 8.1.4B in TS38.214 is voided as follows:
· Section title is changed to “8.1.4B void”
· All contents under section 8.1.4B are deleted
R1-2212823 Correction on duplicated part on UE procedure for determining a resource conflict between TS 38.213 and TS 38.214 Moderator (LG Electronics)
Decision: The draft CR in R1-2212823 is endorsed. Final CR (TS 38.214, Rel-17, CR#0390, Cat F) is agreed in:
R1-2212989 Correction on duplicated part on UE procedure for determining a resource conflict between TS 38.213 and TS 38.214 Moderator (LG Electronics), Samsung, ZTE, Sanechips, Nokia, Nokia Shanghai Bell, NTT DOCOMO, OPPO, Ericsson, Huawei, HiSilicon
Issue 2-16 [Scheme 1] Modification to Step 6) in Section 8.1.4 of TS 38.214 used when UE-A determines a preferred resources set and the time gap from IUC transmission to the preferred resource is larger than (T_(proc,0)^SL+T_(proc,1)^SL+T_(proc,2)^SL)
R1-2211855 Clarification on determination of preferred resource set for IUC scheme 1 Sharp
Issue 2-15 [Scheme 1] Further clarification on the use of preferred resource set for resource reselection due to pre-emption/re-evaluation/conflict information
R1-2211965 Discussion on RAN2-related topics for SL maintenance NTT DOCOMO, INC.
Issue 2-18 [Scheme 2] Correction/clarification on description of valid PSFCH occasion for Scheme 2 in TS 38.213
R1-2212217 [Draft] Clarification on valid PSFCH occasions for resource conflict information Ericsson
R1-2212465 Correction on description of valid PSFCH occasion for scheme 2 in TS 38.213 Huawei, HiSilicon
R1-2212824 Correction on description of valid PSFCH occasion for Scheme 2 Moderator (LG Electronics)
No consensus to proceed further with the proposed TP.
Issue 2-23 [Scheme 1] Further clarification that UE-A is the destination UE of a TB transmitted by UE-B for the case when IUC information is triggered by an explicit request from UE-B and UE-A determines the set of non-preferred resources for UE-B
R1-2212464 Correction on UE-A is the destination UE of a TB transmitted by UE-B in TS 38.214 Huawei, HiSilicon
Issue 2-20 [Scheme 1] Further clarification on condition(s) under which Option B can be used for the received preferred resource set
R1-2211965 Discussion on RAN2-related topics for SL maintenance NTT DOCOMO, INC.
Note: it was decided at RAN1#110bis-e that issue 2-20 in R1-2210333 will not be treated at RAN1#111.
Issue 2-21 [Scheme 1] Addition of procedure that allows UE-B to distinguish between non-preferred resources generated based on different conditions (i.e., Condition 1-B-1, Condition 1-B-2)
R1-2212088 Draft CR on Non-preferred Resources Qualcomm Incorporated
Note: it was decided at RAN1#110bis-e that issue 2-21 in R1-2210333 will not be treated at RAN1#111.
Issue 2-24 [Scheme 1] Further clarification on cast type for IUC scheme 1
R1-2211262 Clarification on cast type for IUC scheme 1 LG Electronics
Agreement
The following working assumption is confirmed as follows:
· Working Assumption (RAN1#107bis-e meeting):
o For Scheme 1, following cast type(s) are supported for inter-UE coordination information transmission triggered by a condition other than explicit request reception
§ Groupcast/Broadcast for
non-preferred resource set, FFS for preferred resource set
·
FFS: Under which conditions groupcast/broadcast can be
supported
§ Unicast for preferred resource set and non-preferred resource set
·
FFS: Under which conditions unicast can be supported
Prepare an LS to RAN2 for the above agreement and ask RAN2 to specify the relevant aspects in their specifications.
R1-2212821 Draft LS on cast types for IUC scheme 1 Moderator (LGE)
Decision: The draft LS in R1-2212821 is endorsed with the following additional text:
· RAN1 has found that the previous working assumption had not been specified in any specification, and would like to ask RAN2 to specify the agreement above in their specification.
Final LS is approved in R1-2212822.
Issue 2-25 [Scheme 2] Further clarification on UE procedure for receiving PSFCH with conflict information
R1-2212205 Clarification on UE procedure for receiving PSFCH with conflict information ZTE, Sanechips
R1-2212906 Correction on UE procedure for receiving PSFCH with conflict information Moderator (LG Electronics)
Conclusion:
This issue is not pursued in Rel-17.
Issue 2-26 [Scheme 2] Correction of misaligned RRC parameter name of indicationUEBScheme2
R1-2212447 Corrections for SL Inter-UE coordination Nokia, Nokia Shanghai Bell
Issue 3-2 Further clarification on which set of SL power control parameters is used by UE
R1-2210895 Correction on power control for PSCCH/PSSCH/PSFCH/S-SSB in TS 38.213 Huawei, HiSilicon
R1-2210979 Correction for SL power control parameters vivo
R1-2212089 Draft CR on Power Control Parameters Qualcomm Incorporated
R1-2212220 [Draft] Modifications on SL open loop power control formulae Ericsson
R1-2212825 Correction on SL open loop power control parameters Moderator (LG Electronics)
Decision: The draft CR in R1-2212825 is endorsed. Final CR (TS 38.213, Rel-17, CR#0436, Cat F) is agreed in:
R1-2212990 Correction on SL open loop power control parameters Moderator (LG Electronics), Samsung, vivo, ZTE, Sanechips, Nokia, Nokia Shanghai Bell, Qualcomm, Ericsson, Huawei, HiSilicon
Final summary in R1-2212820.
R1-2302059 Session notes for 8.11 (Maintenance on NR Sidelink enhancement) Ad-Hoc Chair (Huawei)
[112-R17-SL] – Seungmin (LGE)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
From AI 5
R1-2300016 Reply LS to RAN1 on default CBR configuration RAN2, OPPO
R1-2302073 Discussion summary on default CBR configuration LS from RAN2 Moderator (OPPO)
From Wednesday session
Agreement
Reply to RAN2 as follows:
From RAN1 perspective, whether case 3 is valid or not is the same in Rel-16 as in Rel-17, and therefore RAN1 recommends to RAN2 that the usage of default CBR configuration for full sensing case in R17 is unchanged compared to R16.
R1-2302174 Reply LS to RAN2 on default CBR configuration RAN1, OPPO
Decision in Friday session: The LS is approved.
Maintenance on resource allocation for power saving
R1-2301807 FL summary #1 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
R1-2301808 FL summary #2 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
R1-2301809 FL summary #3 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
R1-2301810 FL summary #4 for AI 8.11: R17 eSL power saving RA maintenance Moderator (OPPO)
Issue PS-1 UE reports a full initialized candidate resource set (SA) when performing random resource selection
R1-2300105 Correction on description of random resource selection in TS 38.214 Huawei, HiSilicon
Issue PS-2 Re-evaluation and pre-emption checking for the case of aperiodic transmission
R1-2300315 Correction on the operation of re-evaluation and/or pre-emption checking for partial sensing Spreadtrum Communications, vivo
R1-2301082 Correction on parameter description for sidelink partial sensing in TS 38.214 ZTE, Sanechips
Agreement
· Endorse the TP (for TS38.214 section 8.1.4) in section 2.2.1 of R1-2301808.
· Final CR (Rel-17, 38.214, CR0405, Cat F) is agreed in
R1-2302175 Correction on reservation periodicity for re-evaluation and pre-emption checking Moderator (OPPO), ZTE, Sanchips, vivo, Spreadtrum, ITL, Huawei, HiSilicon, Samsung, CATT, GOHIGH, Intel
Issue PS-3 Sensing occasions for periodic-based partial sensing (PBPS)
R1-2300422 Correction on the sensing occasions for periodic-based partial sensing vivo
Agreement
· The following TP is endorsed for TS38.214 section 8.1.4:
<Beginning of propose changes>
The
UE monitors k sensing occasion(s) determined by sl-Additional-PBPS-Occasion, as
previously described, and not earlier than 
. For a given
periodicity 
, the values
of k correspond to the most recent sensing occasion earlier than 
if sl-Additional-PBPS-Occasion is not
(pre-)configured, and additionally includes the value of k corresponding
to the last periodic sensing occasion prior to the most recent one if sl-Additional-PBPS-Occasion is
(pre-)configured. 
is the first
slot of the selected Y candidate slots of PBPS.
<End of propose changes>
Final CR (Rel-17, 38.214, CR0406, Cat F) is agreed in
R1-2302176 Correction on periodic-based partial sensing occasion index Moderator (OPPO), ZTE, Sanchips, vivo, Spreadtrum, ITL, Huawei, HiSilicon, Samsung, CATT, GOHIGH, Intel
Issue PS-4 For all partial sensing schemes, clarify resource allocation steps are based on PSCCH decoded and RSRP measured
R1-2300628 Correction on the operations of partial sensing CATT, GOHIGH
Agreement
· The following TP is endorsed for TS38.214 section 8.1.4:
--------- Start of TP --------
When
the UE performs periodic-based partial sensing and contiguous partial sensing
with periodic reservation for another TB (sl-MultiReserveResource)
enabled and 
, the
contiguous partial sensing window is defined by the range of slots 
. n+TA
is M consecutive logical slots earlier than slot , and n+TB
is 
slots
earlier than , where is the first
slot of the selected Y candidate slots of PBPS, and 
, 
are in units
of physical time/slots. The value of M is (pre-)configured with the sl-CPS-WindowPeriodic. The
UE shall perform the behaviour in the following steps based on PSCCH decoded
and RSRP measured in these slots. If sl-CPS-WindowPeriodic is not
(pre-)configured, M equals to 31.
When
the UE performs at least contiguous partial sensing
and if 
,
the contiguous
partial sensing window is defined by the range of
slots .
and
are
both selected such that the UE has sensing results starting at least M
consecutive logical slots before and ending
at slots earlier
than ,
where is
the first slot of the selected 
candidate
slots.
The value of M is (pre-)configured with the sl-CPS-WindowAperiodic.
The
UE shall perform the behaviour in the following steps based on PSCCH decoded
and RSRP measured in these slots. If sl-CPS-WindowAperiodic
is not (pre-)configured, M equals to 31. When the
minimum M slots for CPS cannot be guaranteed and when ,
it is up to UE implementation to either continue with step 3) or perform random
selection.
--------- End of TP --------
Final CR (Rel-17, 38.214, CR0407, Cat F) is agreed in
R1-2302177 Correction on resource selection based on decoded PSCCH and measured RSRP Moderator (OPPO), ZTE, Sanchips, vivo, Spreadtrum, ITL, Huawei, HiSilicon, Samsung, CATT, GOHIGH, Intel
Issue
PS-5 Clarification
of resource sets (
) and (
) are in the qth
reservation period when re-evaluation and pre-emption checking is triggered
R1-2300791 Clarification on pre-emption and re-evaluation for periodic transmission in partial sensing Sharp
Issue
PS-6 Clarification
to avoid 
to take on a zero value
R1-2300792 Clarification on Preserve for periodic based partial sensing Sharp
Issue PS-7 Clarification on candidate slots for aperiodic transmission in partial sensing
R1-2300793 Clarification on candidate slots for aperiodic transmission in partial sensing Sharp
Issue PS-8 Correction on the parameter description for Y’ candidate slots in Step 1
R1-2301082 Correction on parameter description for sidelink partial sensing in TS 38.214 ZTE, Sanechips
Agreement
· Endorse the TP (for TS38.214 section 8.1.4) in section 2.2.2 of R1-2301808.
· Final CR (Rel-17, 38.214, CR0408, Cat F) is agreed in
R1-2302178 Correction on the parameter description for Y’ candidate slots Moderator (OPPO), ZTE, Sanchips, vivo, Spreadtrum, ITL, Huawei, HiSilicon, Samsung, CATT, GOHIGH, Intel
Issue PS-9 Half-duplex issue in re-evaluation and pre-emption checking for partial sensing
For periodic transmission
R1-2301474 Draft CR on half-duplex consideration for SL re-evaluation/pre-emption check NTT DOCOMO, INC.
Final summary in R1-2301811.
Maintenance on inter-UE coordination for mode 2 enhancements, for scheme 1 and for scheme 2, and other miscellaneous issues
R1-2301851 Feature lead summary #1 for AI 8.11: Inter-UE coordination for Mode 2 enhancements and others Moderator (LG Electronics)
Final summary in R1-2301852
Issue #1 in R1-2301851
R1-2300106 Correction on UE-A is the destination UE of a TB transmitted by UE-B in TS 38.214 Huawei, HiSilicon
Issue #2 in R1-2301851
R1-2300200 Clarification for preferred or non-preferred resource set indication Spreadtrum Communications, OPPO, vivo
R1-2302077 Clarification of a field in SCI format 2-C indicating the time offset of the first resource of each tuple with respect to the reference slot Moderator (LG Electronics)
From Wednesday session
Agreement
· The draft CR in R1-2302077 is endorsed.
· Final CR (Rel-17, 38.214, CR0401, Cat F) is agreed in
R1-2302159 Clarification of a field in SCI format 2-C indicating the time offset of the first resource of each tuple with respect to the reference slot Moderator (LG Electronics), ZTE, Sanechips, Spreadtrum Communications, vivo, Samsung, Intel Corporation
Issue #3 in R1-2301851
R1-2300421 Correction on missing field descriptions of SCI 2-C vivo
Issue #4 in R1-2301851
R1-2300505 Some editorial issues in NR_SL_enh - incorrectly implemented TPs Nokia, Nokia Shanghai Bell
R1-2300199 Corrections on misalignment for RRC parameters in TS 38.213 Spreadtrum Communications, vivo
R1-2301083 Miscellaneous corrections on sensing and IUC parameters in TS 38.214 ZTE, Sanechips
Agreement
Issue #5 in R1-2301851
R1-2300629 Correction on resource exclusion behavior with non-preferred resource set CATT, GOHIGH
Issue #6 in R1-2301851
R1-2300630 Correction on the time gap between PSFCH and corresponding SCI format 1-A CATT, GOHIGH
Issue #7 in R1-2301851
R1-2300790 Clarification on determination of preferred and non-preferred resource set for IUC scheme 1 Sharp
Issue #8 in R1-2301851
R1-2300790 Clarification on determination of preferred and non-preferred resource set for IUC scheme 1 Sharp
Issue #9 in R1-2301851
R1-2301085 Correction on IUC scheme 2 in TS 38.213 ZTE, Sanechips
R1-2302078 Clarification on the timeline of transmitting/receiving PSFCH with control information Moderator (LG Electronics)
Agreement
· The draft CR in R1-2302078 is endorsed.
· Final CR (Rel-17, 38.213, CR0449, Cat F) is agreed in
R1-2302160 Clarification on the timeline of transmitting/receiving PSFCH with control information Moderator (LG Electronics), ZTE, Sanechips, Spreadtrum Communications, vivo, Samsung, Intel Corporation
Issue #10 in R1-2301851
R1-2301128 [Draft] Clarification on valid PSFCH occasions for resource conflict information Ericsson
R1-2301704 Correction on description of valid PSFCH occasion for scheme 2 in TS 38.213 Huawei, HiSilicon
Issue #11 in R1-2301851
R1-2301083 Miscellaneous corrections on sensing and IUC parameters in TS 38.214 ZTE, Sanechips
R1-2302079 Correction on the resource selection mechanism indicated by higher layer Moderator (LG Electronics)
From Wednesday session
Agreement
The following TP for TS38.214 is endorsed:
---------- Start of the TP ---------
<Unchanged parts omitted>
8.1.4 UE procedure for determining the subset of resources to be reported to higher layers in PSSCH resource selection in sidelink resource allocation mode 2
In resource allocation mode 2, the higher layer can request the UE to determine a subset of resources from which the higher layer will select resources for PSSCH/PSCCH transmission. To trigger this procedure, in slot n, the higher layer provides the following parameters for this PSSCH/PSCCH transmission:
- the resource pool from which the resources are to be reported;
- L1 priority, 
;
- the remaining packet delay budget;
- the number of
sub-channels to be used for the PSSCH/PSCCH transmission in a slot, 
;
- optionally, the
resource reservation interval, 
, in units of msec.
- if the
higher layer requests the UE to determine a subset of resources from
which the higher layer will select resources for PSSCH/PSCCH transmission as part of
re-evaluation or pre-emption procedure, the higher layer provides a set of
resources 
which may be
subject to re-evaluation and a set of resources 
which may be
subject to pre-emption.
- it is up to
UE implementation to determine the subset of resources as requested by higher
layers
before or after the slot 
- 
, where is the slot
with the smallest slot index among and , and is equal to , where 
is defined in
slots in Table 8.1.4-2 where 
is the SCS
configuration of the SL BWP.
- Optionally,
the
indication of resource selection mechanism(s),
as sl-AllowedResourceSelectionConfig, which
may comprise of full sensing only, partial
sensing only, random resource selection only, or any combination(s) thereof.
The following higher layer parameters affect this procedure:
- sl-SelectionWindowList: internal
parameter 
is set to
the corresponding value from higher layer parameter sl-SelectionWindowList
for the given value of .
- sl-Thres-RSRP-List: this higher
layer parameter provides an RSRP threshold for each combination 
, where 
is the value
of the priority field in a received SCI format 1-A and 
is the
priority of the transmission of the UE selecting resources; for a given
invocation of this procedure, 
.
- sl-RS-ForSensing selects if the UE uses the PSSCH-RSRP or PSCCH-RSRP measurement, as defined in clause 8.4.2.1.
- sl-ResourceReservePeriodList
- sl-SensingWindow: internal
parameter 
is defined
as the number of slots corresponding to sl-SensingWindow msec
- sl-TxPercentageList:
internal parameter 
for
a given is
defined as sl-TxPercentageList ()
converted from percentage to ratio
- sl-PreemptionEnable: if sl-PreemptionEnable
is
provided, and if it is not equal to 'enabled', internal parameter 
is set to
the higher layer provided parameter sl-PreemptionEnable.
<Unchanged parts omitted>
---------- End of the TP ---------
Final CR (Rel-17, 38.214, CR0402, Cat F) is agreed in
R1-2302161 Correction on the resource selection mechanism indicated by higher layer Moderator (LG Electronics), ZTE, Sanechips, Spreadtrum Communications, vivo, Samsung, Intel Corporation, Huawei, HiSilicon
Issue #12 in R1-2301851
R1-2301084 Correction on sidelink power control procedure in TS 38.213 ZTE, Sanechips
